Сборка расто-кода автотулзами

О Боги, я был готов к худшему, но по ссылке хуже того худшего.

автотулзы официально зашкварены

Какое изысканное самоистязание.

Да, хуже них даже не знаю что… разве только сборка «руками» через bat-ники (видел такое у некоторых коллег).

Любители тонких извращений.

Майнинг злое зло, покайся.

раст готов для десктопа !

Лол, а при чем тут раст-то? Там почти весь проект на плюсах.

ну человек умеет только в автолулзы, ну что ж тут поделаешь? зато написано аккуратно, в общем не вижу в этом проблем, кроме того, что в 2к21 уже переставать использовать и переходить на более современные средства

Вопрос: как еще вы собрались собирать код на расте в проекте на крестах? Растолюбы нахваливают карго, мол "(пока что) единый инструмент для сборки", но что они собралаись делать, если код на расте использует сишную либу? А если код на паскале дергает растовый код? Вариант только один — внешний инструмент, который будет дергать карго и потом лепить выхлоп ко внешним либам.

но что они собралаись делать, если код на расте использует сишную либу?

А он дергает во множестве случаев. Всякие байдинги к Gtk, SQLite, OpenSSL.

Работает, хотя это невозможно согласно твоих глубоких познаний сборки Rust приложений. Странно, да?

Внутренний инструмент - build.rs, который будет дёргать внешний.

Выпнуть дебильный негерметичный online-only cargo на мороз и дёргать компилятор. К слову, для сборки просто раста все равно так делать.

но что они собралаись делать, если код на расте использует сишную либу?

А он дергает во множестве случаев. Всякие байдинги к Gtk, SQLite, OpenSSL

У Gtk+ кастомный генератор кода, который опирается на конкретную фичу интроспекции у GObject.

Rusqlite использует несколько вариантов, из которых основным является динамическое линкование и предварительно сгенерированные биндинги (что не требует работы со сторонним ЯП), а альтернативой им — компиляция sqlite через сc и генерация биндингов шлангом через bindgen.

Как ты видишь, при возникновении второго ЯП сборка при помощи cargo резко становится нетривиальной задачей.

Внутренний инструмент - build.rs, который будет дёргать внешний

Но по итогу многие из них сводятся к тому, чтобы дернуть внешнюю команду, вроде clang.

Всю нетривиальность уже завернули в build crates вроде cc и cmake и пишут короткие скрипты в build.rs

Выпнуть дебильный негерметичный online-only cargo на мороз и дёргать компилятор. К слову, для сборки просто раста все равно так делать

Ну да. Это дебильная современная мода на онлайн репозитории, которыми через пять лет уже ничерта не соберешь. Удачи при помощи этого делать что-то серьезное и долговременное. Мне вот страшно представить, что будет, если спустя десять лет мне поручат собрать проект SPA на JS, который я нынче разрабатываю. Он и сейчас не всегда собирается, потому что NPM представляет собой сплошное казино — а то через десять лет.

Всю нетривиальность уже завернули в build crates вроде cc и cmake и пишут короткие скрипты в build.rs

Да, и потому основным методом линкования с сишными зависимостями является динамическая линковка с готовыми бинарями.

Ну. Ты спросил - я ответил. Это ведь и требовалось показать - что мы не будем жрать говнину под именем autotools. Да, собирать ими будем, но ни строчки самим писать не придётся.

Каждый раз cargo сравнивают с npm, почему? Почему не с pip/gradle/maven/cabal/etc.? И если какой-то особой причины нет, то почему cargo обязан повторить опыт именно npm?

Мне вот страшно представить, что будет, если спустя десять лет мне поручат собрать проект SPA на JS, который я нынче разрабатываю.

В расте это уже не проблема cargo vendor https://doc.rust-lang.org/edition-guide/rust-next/cargo-vendor.html скачает все зависимости в отдельную папку и все будет собираться полностью оффлайн.

Каждый раз cargo сравнивают с npm, почему? Почему не с pip/gradle/maven/cabal/etc.? И если какой-то особой причины нет, то почему cargo обязан повторить опыт именно npm?

PIP — та же срань. Когда ставишь что-то тривиальное — получается еще более-менее. А как подходишь к TensorFlow, Graphviz, SciPy, PyPy, Qt, Gtk, то начинаются радости с весельями. Отсюда и возникла та же анаконда, которая умеет просто ставиться и работать.

В расте это уже не проблема cargo vendor https://doc.rust-lang.org/edition-guide/rust-next/cargo-vendor.html скачает все зависимости в отдельную папку и все будет собираться полностью оффлайн

С чем я растолюбов и поздравляю.

Это ещё раз доказывает, что автотулзы — проверенный временем надёжный инструмент, могущий в сбору любого современного и модного ненужно!

Опять весь проект переписать не осилили, лишь чутка подпортили его.

проверенный временем надёжный инструмент

Точно. Автолулзы - это «глобально и надёжно» (c) (tm).

💪🏻autotools

но что они собралаись делать, если код на расте использует сишную либу?

Вообще не проблема.

Лучше через ant сделайте. Это более надёжно и предсказуемо. Заодно можно и в maven-репозиториях попробовать захостить rust-артефакты.

Потому что есть маленькие тихие помойки, а есть эпические.

А в чём проблема? Если я соберусь писать на расте, я точно буду собирать проекты нормальными системами сборки (не autocrap конечно), и тянуть зависимости из системы. Никаких cargo тянущих трояны или гнильё.

что за автотулзофобия, где твоя толерантнось к разнообразию систем сборки

но что они собралаись делать, если код на расте использует сишную либу?

Пакетный менеджер, pkgconfig? Не, не слышали.

но что они собралаись делать, если код на расте использует сишную либу?

Пакетный менеджер, pkgconfig? Не, не слышали

Да, и автотулз.

Да, и автотулз.

Craptools – это лишнее. Им место в музее.

У Autotools огромное число проблем, по сути это набор лютых костылей для сборки на всяких древних UNIX’ах, которые уже несколько десяток лет как не поддерживают, а часть фирм их делающих вообще закрылись. Один процесс configure с тестированием компилятора на всякие мелочи чего стоит. В здравом уме до такого невозможно было додуматься.

У Autotools огромное число проблем,

Не больше, чем у остальных

для сборки на всяких древних UNIX’ах

на современных тоже прекрасно собирает, и их много разных (ОS X, BSD)

Один процесс configure с тестированием компилятора на всякие мелочи чего стоит.

Не все сборочные хосты имеют одинаковые компиляторы последней версии

Не больше, чем у остальных

Намного больше. Я без проблем могу добавить в проект на Jam, Cmake или Meson новые компоненты не читая документацию. А в Autotools всё сыпется по непонятной причине и я даже не хочу разбираться почему (пробовал чистить сборку и переконфигурировать, регенерировать файл configure, не помогло). Проще весь проект перенести на другую систему сборки, чем разбираться с Autotools. Autotools ещё часто содержит прибитые гвоздями пути и неправильно распознаёт библиотеки зависимостей.

Не все сборочные хосты имеют одинаковые компиляторы последней версии

Есть стандарты языков C и C++, компиляторы их не поддерживающие оправляются на помойку. Даже примитивный TCC соответствует стандарту C99.

Я без проблем могу добавить в проект на Jam, Cmake или Meson новые компоненты не читая документацию.

Ну враньё же. Для cmake для каждой зависимости надо отдельный модуль писать, который будет её искать, для этого нужно вкуривать наркоманский синтаксис CMake-а.

А в Autotools всё сыпется по непонятной причине и я даже не хочу разбираться почему

Читать документацию полезно, у автотулзов она и не очень объёмная.

Для cmake для каждой зависимости надо отдельный модуль писать, который будет её искать

4.2. Ничего не надо писать, Cmake понимает pkgconfig.

Читать документацию полезно, у автотулзов она и не очень объёмная.

А ещё надо прочитать документацию на m4 (впервые узнал из Autotools что такое вообще существует), всякие трюки Bash и чего там ещё приделано синей изолентой.

Cmake понимает pkgconfig.

так и автотулзы точно так же его понимают, но отдельный модуль пилить обычно не требуется

но отдельный модуль пилить обычно не требуется

В Cmake эти модули нужны разве что для особо кривых дистрибутивов и Windows. Без них можно спокойно обойтись, на тяжёлый случай можно пути руками прописать. В некоторых кривых модулях возможность прописать пути руками поломана.

так и автотулзы точно так же его понимают

Autotools сам на 90% состоит из таких модулей для поддержки мёртвых UNIX’ов 40 летней давности.

В Cmake эти модули нужны разве что для особо кривых дистрибутивов и Windows. Без них можно спокойно обойтись,

Ни разу не видел ещё более-менее крупный проект, который не тащил бы самописные модули для зависимостей с собой

на тяжёлый случай можно пути руками прописать.
Autotools ещё часто содержит прибитые гвоздями пути

но автотулзы плохие, а симейк хороший

Autotools сам на 90% состоит из таких модулей для поддержки мёртвых UNIX’ов 40 летней давности.

покажи хоть один

Ни разу не видел ещё более-менее крупный проект, который не тащил бы самописные модули для зависимостей с собой

Дай угадаю, они для Windows собираются? Autotools под Windows не работает без эмуляции POSIX среды.

но автотулзы плохие, а симейк хороший

Прописывать пути руками – это единственный правильный метод если нет системы централизованного хранения объявлений библиотек вроде pkgconfig.

покажи хоть один

https://gitlab.freedesktop.org/xorg/util/macros. В исходниках самого Autotools есть прибитые гвоздями пути вроде /usr (например в Haiku нет никакого usr).

Дай угадаю, они для Windows собираются? Autotools под Windows не работает без эмуляции POSIX среды.

Но эмуляция POSIX среды в Windows - работает. В ассортименте. И для Windows в том числе тоже, помимо остальных платформ.

В исходниках самого Autotools есть прибитые гвоздями пути вроде /usr

autotools ориентируется на юниксовый FHS, и нет ничего удивительного, что дефолтные пути могут содержать /usr. Но все пути можно менять параметрами configure скрипта либо переменными окружения и успешно собирать в любой наркоманской ОС без /usr

Сектант всегда сектант. Даже дерьмо оно будет воровать. Главное, что бы самим ничего делать не пришлось(даже дерьмо). Уровень.

Деревенский сумасшедший - всегда сумасшедший. Опять забыл таблетки принять и галлюцинируешь на публике? Хоть штаны не испачкай, бедолага)0