Обновить
Комментарии 17

Всё вроде бы неплохо со своими велосипедными системами сборки… До тех пор, пока ты не захочешь использовать современные IDE или интегрировать что-то с другими сторонними инструментами. База данных компиляции конечно может помочь в некотором роде, но в этом случае придется её генерировать для каждой цели, что очень неудобно. Ну и есть ещё множество нюансов. С этим проблемы возникают даже в больших компаниях с ресурсами, что уж говорить о мелких.


Но, если я буду писать свое следующие приложение на C/C++ для сборки я, наверное, все же буду использовать CMake. Ну потому что, это CMake :)

Вот это хороший вывод :) За статью спасибо.

А хотя бы инклюды он ассоциирует с артефактами так чтобы изменение заголовочника пересобирало все бинари его использующие?
Посмотрите в сторону qbs, тоже декларативный синтаксис, но более однородная среда и не прибита гвоздями к С++

А хотя бы инклюды он ассоциирует с артефактами так чтобы изменение заголовочника пересобирало все бинари его использующие?

Да конечно, это же прям базовый функционал.

Про Qbs, я почему-то сначала подумал про qmake, а нет, это что-то новое. Давно не заглядывал в мир Qt. Посмотрю на досуге, спасибо.

Qbs уже давно не поддерживается. Нет смысла смотреть.

Хотя у кутешников опять какое-то раздвоение личности. То говорили, что прекратят разработку в 2019 (https://www.qt.io/blog/2018/10/29/deprecation-of-qbs), теперь оказывается, что все-таки поддерживают до сих пор (https://download.qt.io/official_releases/qbs/1.17.0/). В общем непонятно и стремно.

Это уже не ку-тешники, а комьюнити. И развивается даже быстрее чем было при ку-тешниках.

Кроме того комьюнити для Qbs пилит плагин для VSCode: github.com/denis-shienkov/vscode-qbs

Скоро анонс на хабр постараюсь добавить (плагин в принципе уже готов). ;)
> Посмотрите в сторону qbs, тоже декларативный синтаксис, но более однородная среда и не прибита гвоздями к С++

Неистово плюсую этого господина, тем более, что уже готовится к релизу плагин для VSCode.
Этой весной решил поискать альтернативы CMake, много лет в основном ей пользовался, реже qmake, autoconf и непосредственно make. Попробовал сначала gradle, потом bazel, в итоге на последнем и остановился. Синтаксис довольно прост, кросскомпиляцию поддерживает нормально (в отличие от gradle, долго с ней мучался), интеграция с IDE тоже, скорость устраивает. Не без косяков конечно, но потихоньку все устраняется, проект развивается. Команды для тестирования, покрытия тестами, запуск через valgrind имеются из коробки. Если надо логику для компиляции прикрутить, используется в файлах сборки язык starlark, по синтаксису как python. Всякие гетерогенные проекты можно собирать. В общем меня устраивает, полгода пользуюсь, не нарадуюсь.

Когда мне надоел "птичий язык" Make я стал искать альтернативу и перешёл на Rake где используется Ruby. Теперь если надо добавить в сборку что-нибудь этакое (например компилировать определенный каталог с другими флагами или добавлять номер коммита в выходной файл в виде константы), я не гуглю как это сделать в моей системе сборки, а сразу пишу. Из-за этого на системы сборки использующие свой язык я смотрю с предубеждением. Правда у меня проекты относительно небольшие (прошивки для микроконтроллеров).

Да, Rake мы тоже используем, но только уже для вызова Bake или для реализации каких-то сложных шагов пост(пре)-сборки.

НЛО прилетело и опубликовало эту надпись здесь
А что вы предполагаете под сложными системами? Какой критерий для их определения? Я бы не был так категоричен.

У меня есть примеры использвования CMake при разработке автомобильного ПО всех уровней. В моем понимании они попадают под категорию сложных систем.

Ну или, например, проект LLVM. Еще можно привести много достаточно больших открытых проектов, использующих CMake. А большая кодовая база уже подразумевает некоторую сложность.

Про критерии мне тоже было бы интересно узнать.


Порой наблюдаешь странный гибрид из менеджера пакетов, собственно системы сборки, скриптов CI и много чего другого, а когда пытаешь узнать почему так, в ответ получаешь "сложная система". Да, чёрт побери, она теперь сложная! Мы же не умеем декомпозировать, не имеем доступа к существующим решениям, не знаем как вносить свой вклад в проекты с открытым исходным кодом, да и вообще всё это долго, дорого и отстаньте...

Ага, и до сих пор они домучать этот CMake не могут.

Только из за того что бизнес хочет цмейк, и замечу цмейк до сих пор не осилили, хотя сборку на qbs делало гораздо меньше людей а полная сборка Qt появилась уже давно

Ну, размер проекта понятие относительное.
Кто-то считает LLVM и Qt большими проектами, а кто-то — маленькими=)
Просто когда у вас пара терабайт кода, там начинаются пляски с бубнами вокруг системы сборки/системы контроля версий и прочего — догадываться что изначально имелось ввиду под «большим проектом» — дело неблагодарное.
Вообще, интересно сравнить один и тот же проект на разных системах сборки, но, к сожалению, это редко возможно — никто не хочет поддерживать зоопарк билдсистем. Я сравнивал сборку QtCreator с qbs/cmake — full build быстрее у qbs (~2.5 минуты разницы), null build быстрее у cmake+ninja (аж в 2 раза — 1.1 секунды против 2). Конфигурация у qbs чуть медленнее (к сожалению, данные не сохранил).

Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.