Comments 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
Скоро анонс на хабр постараюсь добавить (плагин в принципе уже готов). ;)
Неистово плюсую этого господина, тем более, что уже готовится к релизу плагин для VSCode.
Когда мне надоел "птичий язык" Make я стал искать альтернативу и перешёл на Rake где используется Ruby. Теперь если надо добавить в сборку что-нибудь этакое (например компилировать определенный каталог с другими флагами или добавлять номер коммита в выходной файл в виде константы), я не гуглю как это сделать в моей системе сборки, а сразу пишу. Из-за этого на системы сборки использующие свой язык я смотрю с предубеждением. Правда у меня проекты относительно небольшие (прошивки для микроконтроллеров).
У меня есть примеры использвования CMake при разработке автомобильного ПО всех уровней. В моем понимании они попадают под категорию сложных систем.
Ну или, например, проект LLVM. Еще можно привести много достаточно больших открытых проектов, использующих CMake. А большая кодовая база уже подразумевает некоторую сложность.
Про критерии мне тоже было бы интересно узнать.
Порой наблюдаешь странный гибрид из менеджера пакетов, собственно системы сборки, скриптов CI и много чего другого, а когда пытаешь узнать почему так, в ответ получаешь "сложная система". Да, чёрт побери, она теперь сложная! Мы же не умеем декомпозировать, не имеем доступа к существующим решениям, не знаем как вносить свой вклад в проекты с открытым исходным кодом, да и вообще всё это долго, дорого и отстаньте...
Только из за того что бизнес хочет цмейк, и замечу цмейк до сих пор не осилили, хотя сборку на qbs делало гораздо меньше людей а полная сборка Qt появилась уже давно
Кто-то считает LLVM и Qt большими проектами, а кто-то — маленькими=)
Просто когда у вас пара терабайт кода, там начинаются пляски с бубнами вокруг системы сборки/системы контроля версий и прочего — догадываться что изначально имелось ввиду под «большим проектом» — дело неблагодарное.
Вообще, интересно сравнить один и тот же проект на разных системах сборки, но, к сожалению, это редко возможно — никто не хочет поддерживать зоопарк билдсистем. Я сравнивал сборку QtCreator с qbs/cmake — full build быстрее у qbs (~2.5 минуты разницы), null build быстрее у cmake+ninja (аж в 2 раза — 1.1 секунды против 2). Конфигурация у qbs чуть медленнее (к сожалению, данные не сохранил).
Готовим C++. Система сборки Bake