MB
Нельзя, мутабельной ссылки нет.
Arc::get_mut
Size: a a a
2020 September 25
R
Можно, если умеючи )
R
Вообще оч полезно. Что б вызвать код последнему владельцу чего-нибудь
ST
Есть несколько крейтов объединённых в одном пакете, рутовый Cargo.toml - "виртуальный" (virtual manifest). Хочется выполнять код при сборке любого из крейтов (ну или всего целиком), но build.rs на этом уровне не работает.
Можно ли как-то выкрутиться красивее, чем положить build.rs к крейту от которого зависят все остальные?
Можно ли как-то выкрутиться красивее, чем положить build.rs к крейту от которого зависят все остальные?
Э
Есть несколько крейтов объединённых в одном пакете, рутовый Cargo.toml - "виртуальный" (virtual manifest). Хочется выполнять код при сборке любого из крейтов (ну или всего целиком), но build.rs на этом уровне не работает.
Можно ли как-то выкрутиться красивее, чем положить build.rs к крейту от которого зависят все остальные?
Можно ли как-то выкрутиться красивее, чем положить build.rs к крейту от которого зависят все остальные?
Сделать один из крейтов шапкой, чтобы не был виртуальный воркспейс?
ST
Ну это почти то же самое, что и пихнуть build.rs к одному из крейтов?
Плюс сразу вопрос какой крейт делать "самым главным", если у меня там несколько библиотек и бинарей.
Плюс сразу вопрос какой крейт делать "самым главным", если у меня там несколько библиотек и бинарей.
D
Ну это почти то же самое, что и пихнуть build.rs к одному из крейтов?
Плюс сразу вопрос какой крейт делать "самым главным", если у меня там несколько библиотек и бинарей.
Плюс сразу вопрос какой крейт делать "самым главным", если у меня там несколько библиотек и бинарей.
ST
Как раз в эту сторону и думал, но уж больно костыльно. (:
Но видимо деваться некуда, спасибо.
Но видимо деваться некуда, спасибо.
D
в качестве альтернативы могу предложить сделать крейт (скажем,
потом в
и запускать билд не через
но не уверен, что это менее костыльно :)
xbuild), выполняющий нужные махинации и запускающий cargo buildпотом в
.cargo/config добавить[alias]
xbuild = "run --bin xbuild --"
и запускать билд не через
cargo build, а через cargo xbuildно не уверен, что это менее костыльно :)
ST
в качестве альтернативы могу предложить сделать крейт (скажем,
потом в
и запускать билд не через
но не уверен, что это менее костыльно :)
xbuild), выполняющий нужные махинации и запускающий cargo buildпотом в
.cargo/config добавить[alias]
xbuild = "run --bin xbuild --"
и запускать билд не через
cargo build, а через cargo xbuildно не уверен, что это менее костыльно :)
Вот это любопытный способ. А прям
cargo build так переопределить нельзя?D
Вот это любопытный способ. А прям
cargo build так переопределить нельзя?хм, а не знаю даже, не пробовал, но подозреваю, что не получится) а если вдруг получится — то как тогда запускать оригинальный билд? :)
ST
Ну в моём случае оно и не нужно. (:
Правда тут другая проблема - это решает вопрос с
Правда тут другая проблема - это решает вопрос с
cargo build, но не с cargo test, например.D
cargo xbuild buildcargo xbuild test:)
c
cargo xbuild buildcargo xbuild test:)
тогда уж красиво сделать:
чтобы
[alias]
x = "run --bin xbuild --"чтобы
cargo x buildcargo x testD
как вариант
Э
Мне кажется, или вы там cargo-xtask велосипедируете?
IG
Можно ли кастомизировать при помощи #[cfg] код в зависимости от overflow-checks? Например, чтобы кастомные длинные типы вели себя как native типы?
#[cfg(debug_assertions)] не подходит, потому что overflow-checks - отдельный флаг
#[cfg(debug_assertions)] не подходит, потому что overflow-checks - отдельный флаг
Э
Можно ли кастомизировать при помощи #[cfg] код в зависимости от overflow-checks? Например, чтобы кастомные длинные типы вели себя как native типы?
#[cfg(debug_assertions)] не подходит, потому что overflow-checks - отдельный флаг
#[cfg(debug_assertions)] не подходит, потому что overflow-checks - отдельный флаг