генеримые бинари с помощью build.rs или еще каких ухищрений?
Чтобы под linux генерить SOшки c именем, содержащим версию (libfoо.so.0.0.1), и с проставленным SONAME (флаги для SONAME раскопал, но достать имя бинаря, кроме как распарсив Cargo.toml, не нашел. И возможности поменять конеченое имя артефакта в билдскрипте тоже не наблюдаю).
А под windows вкомпиливать содержимое version.rc (https://pisoft.ru/verstak/insider/cw_ver1.htm), чтобы виндовые инспекторы приложений радовались.
А то забава с "а давайте очень маленькую и простую либину сделаем на Rust" вышла из под контроля...
build.rs не является полной заменой системы сборки. Что вы используете для компиляции под разные платформы? Вот там добавить дополнительные шаги.
Ещё, вроде как, cargo устанавливает переменные окружения с именем, версией и прочим. Так что парсить toml не нужно
Установлены имя пакета и версия его. А вот имя конкретного собираемого бинаря (lib.name) — не видать на этапе build.rs
Типа libXXX.so/XXX.dll? Этого нет, да
Пока build.rs как точки входа в сборочную систему хватало. Понятное дело, что все эти переименования можно навернуть отдельно и потом. И скорее всего только так и придется. Основная проблема, которую не понятно как решать: как вкомпиливать эти виндовые символы, чтобы они остались, а не были выпилены за ненадобностью. В сишных и плюсовых версиях объектник средствами cmake цеплялся. Как то же самое сделать для библиотек, собранных rustc?
Вкомпиливанием дополнительных библиотек занимается линкер. Виндовыми сборками давно не занимался, но вроде бы должно быть достаточно вывести cargo:rustc-link-lib=rc.res в build.rs
Обсуждают сегодня