Comments 18
Систем сборки же так мало, правда? Ещё одна точно не будет пятнадцатым стандартом, правда?
И все они настолько глючные, сложные и костыльные, что проще сделать свою, чем пытаться разобраться и пропатчить существующие. Кроме того компания размером с небольшую страну (по экономике) может себе позволить.
Тут круто совместимость в Гугловским bazel. То есть это не новый стандарт, а реализация существующего сравнительно популярного. На Rust вместо Java, так что лучше производительность, и ещё немного улучшений. Хороших систем распределенной сборки не так много.
Все носятся с этой корректностью зависимостей (что изменение в файле должно стриггерить пересборку всего, что от него зависит), но на практике это может приводить к огромному оверхеду. Типичный случай: работаешь над небольшой библиотекой, непрерывно делая в ней много мелких изменений. Почти на каждое изменение компилируешь и запускаешь юнит-тест, чтобы убедиться в его правильности. Тест обычно маленький и собирается/запускается быстро. Но проблема, когда в масштабе всей системы сборки от этой библиотеки также зависит гигантский бинарник (основной продукт). "Корректные" системы сборки, вроде tup или buck2, будут пересобирать основной бинарник и вообще пол-проекта на каждое изменение библиотеки.
Нет, не будут. Если тест не зависит от бинарника, а только от библиотеки, то для запуска тестов будет собираться только библиотека, и сами тесты, но не бинарник. По крайней мере Bazel / Blaze так делают.
Основной бинарь должен собраться и протестироваться при любых изменениях библиотеки от которой он зависит. Trunk based development. Это понятно и разумно. Ломать продукт изменением его зависимостей не надо. Что не так?
Обычно есть способ до формирования окончательного PR в репозиторий погонять тесты выборочно. Им все и пользуются. А уже когда все готово ночью идут тесты всего-всего.
Не менять просто так то от чего куча всего зависит это хорошо. Стабильность это очень важно. Забор повыше в этом месте нужен и полезен.
Они реализовали гугловский Bazel. Если тест не зависит от большого бинарника, он не компилирует эти ненужные бинарники для запуска теста.
У таких систем сборки обычно не одна кнопка "собрать всё", а указывается итоговая цель сборки и собирается только она и то от чего она зависит. Когда ты хочешь запустить тест, ты просишь систему сборки собрать тест, а не все доступные цели в проекте. Так было ещё во времена Makefile и более навороченные системы тоже это умеют.
Все ждали что раст заменит плюсы, но раст заменяет джаву)
А, например, оно может собирать без адаптации (или с минимальной типа декларации зависимостей) CMake библиотеки? А то ведь в C++ мире это доминирующая система сборки и когда ты приносишь в проект очередную библиотеку шанс наличия в её корне CMakeLists.txt значительно выше, чем любого другого конфига сборки.
Повоевал в свое время с Базелем в rust проекте. Это прямо сплошные муки, сложные рулы, какие-то адские приседания для того, чтобы нативные библиотеки тянуть, жуткий костыль cargo raze, который потом ещё не менее жутким костылем заменили. Невозможно нормально юзать cargo плагины, да и для rust analyzer генератор какой-то стрёмный.
Короче, вот cargo простой и тупой как автомат Калашникова, а в таких системах просто жуткий overengineering. Куда проще оказалось совмещать cargo и nix.
Просто Cargo — это не универсальная система сборки. Хорошо, потому что работает прекрасно, пока используешь с чисто растовыми проектами. Плохо, когда требуется cargo интегрировать с чем-то ещё. В частности, машино-читаемый формат выдачи результатов теста уже пять лет не могут стабилизировать.
Извините за оффтоп. Работаю с cmake в Qt Creator. Постоянно забываю где и как подключить в cmake очередной .cpp, .h (но не забываю в коде сам include) и получаю ошибку при сборке (не найдет файл). Но при этом сама IDE почему-то прекрасно знает про "ненайденный" файл, потому что работают функции перехода по определению к функциям из этого "неподключенного" файла. При этом по коду C++ IDE делает потрясающие варнинги, в том числе постоянно поправляет меня при работе с указателями. Вопрос. Почему связь с cmake такая никокая? Где подсказки? Ведь cmake действительно доминирующая система сборки в давно существующем мире C++.
Скорее всего это проблема Qt Creator. Может настройки или сама IDE такая. CLion прекрасно сообщает о забытых зависимостях и предлагает добавить их
Qt creator последних версий использует clangd
Cmake предоставляет api для того что творится в проекте
Скорей всего Qt Creator посылает в clangd всю папку, а не те файлы про которые ему говорит cmake.
Meta* представила систему сборки Buck2