Comments 7
простые проблемы обязаны иметь простые решения. точка.
как показала Практика, пользователям вполне достаточно обычного bat файла. например, вот так собирается DebRel:
@set CC=g++
@set FLAGS=-static -std=c++14 -Ofast -DNDEBUG -pedantic -Wall
@set DERSLIB=..\derslib
@set INC=-I%DERSLIB%\inc
%CC% %FLAGS% %INC% *.cpp %DERSLIB%\src\unity\build.cpp %DERSLIB%\src\posix\unity\build.cpp -o debrel 1>1.build 2>2.buildда, можно спорить, что разработчикам (не пользователям) необходима сложная утилита "с полным отслеживанием" зависимостей... вот только в них ОБЯЗАТЕЛЬНО есть проблемы! как знают дедушки, видишь ДИЧЬ - сделай полный ребилд! ага, тем самым батником быстрее будет.
ЗЫ никто ж не спорит, что распределенная система сборки БОЛЬШОГО проекта - must have! т.к. зачем ждать шесть часов, если можно на десять минут. вот только малые и средние проекты... не надо тянуть бегемотов, чья сложность больше, чем у задачи ;)
У меня самой большой проблемой было отсутствие понимания связи переменных в IDE. В связи с чем разобраться в системах сборки крайне сложно.
В одном из проектов использовался Make. Но, как обычно, были какие-то переменные окрыжения, которые останавливались bash скрипом, а то и сверху делают какой-нибудь Python сурипт, скажем для определения таргета и развязки зависимостей от платформы.
В результате, читать это всë и понимать очень сложно. Нашëл переменную и ищешь еë просто поиском по всму, потому что никогда не угадаешь каким именно образом она задается и в каком файле.
В результате у меня вопрос на который я не могу найти ответа. Ведь в проекте все равно будет какой-нибудь CI, скажем условный GitLab CI. Как по мне, так проще написать на нкго 1 раз пайплайн, благо эта тема исписана вдоль и поперёк. И если хочется билдить локадьно - прикрутить в контейнере CI agent ноду и использовать всë тот же пайплайн. Как по мне ты получаешь стандартное решение понятное большинству. Плюс, избегаешь мороки с поиском переменых. Они все так же стандартно задаются через знакомый CI. Нет нужды прикручивать и обкладыватьмя скриптами.
а для Windows бинарные артефакты не публикуются.
А это что? Так же есть сборки х86 и х86_64 отдельно llvm для винды
Не увидел сравнения с nix.
Для сборки си/с++ он подходит идеально, потому что в nixpkgs есть все мыслимые и немыслимые библиотеки и зависимости, вероятность того что нужно будет руками пакетировать что-то крайне мала. Повторяемость из коробки.
спасибо за статью, необычно видеть грэдл в качестве выбора системы сборки под плюсы) Но для «стандартного» проекта выглядит как перебор имхо.
Хотел спросить как интегрировать Qt в грэдл проект, а уже и плагин есть, оказывается: https://github.com/axmetishe/gradle-qt-plugin
Предположим, для юнит-тестов необходимо загрузить некий бинарный артефакт из сети.
Я простого пути «в лоб» так и не нашел.
add_custom_target либо add_custom_command + cmake -P в качестве команды позволит использовать все встроенные средства смаке в своем кастомном скрипте, например тот же file(DOWNLOAD).
В CMake необходимо сначала писать conan.txt, там описывать свои зависимости и опции, а далее запускать генератор для CMake в Conan
есть официальный «плагин» для смаке, который сам вызовет conan install на этапе смаке конфигурации
Билд, который построил Gradle: разбираемся в современной сборке проектов под C++