hpp vs cpp

Как поучаствуешь в проекте на 50+ разработчиков, поймёшь.

Ну ты уж все-таки поясни, ато этой фразой что угодно прикрыть можно.

Чем мейк мешает в проекте на 50 разработчиков? И как помогают ваши бестпрактисы в этом? (спасибо Слаквариору за слово)

Что вообще за смесь мух с котлетами? Как связана система сборки и количество разработчиков? Вы там все впятидесятером одновременно что-ли один и тот же мейкфайл бросаетесь редактировать? А кто всем этим руководит? Аджайл ваш проклятый? )

Вы там все впятидесятером одновременно что-ли один и тот же мейкфайл бросаетесь редактировать? А кто всем этим руководит? Аджайл ваш проклятый? )

Вспоминается прямо как старик Хоттабыч первый раз пришёл на футбол и удивлялся что толпа взрослых мужиков бегает за одним мячиком:-)

От того, что вы лично «развесистый шаблониум» не написали, он никуда не пропадет.

Инклюд шаблонов не влияет почти ни на что, влияет инстацирование шаблонов.

И есть лайфхаки как ограничится инстацированием сложных шаблонов в одной единице трансляции и дальше линкер в помощь. У Вандервуда это описано.

если метод а лучше метода б в 99 случаев из 100, а в 1 хуже, то, очевидно, метод а лучше, так как метод б в 99 случаев хуже.

Если Вы свою статистику набрали на лично своих хеллоуворлдах и пытаетесь её теперь натянуть на весьмир, то это как бэ такое… Не надо так делать.

Скажем у нас типичный размер проекта первые тысячи строк кода, очень редко больше. Шаблонов овердофигища. И при этом единиц трансляции 2…5 шт, и это очень по делу, в тч потому что некоторые части компилятся долго из за шаблонов, а некоторые компилятся долго потому что SWIG там много всего нагенерил и оно толстое. Если бы это все собиралось одним куском то работать было бы невозможно.

И там цмейка нет :)

Есть. И я даже тебе больше скажу - он даже им успешно собирается. Во всяком случае большая часть модулей точно, прям все-все не проверял.

каждые полгода

CMake является самой популярной системой сборки уже много лет. Если ты захочешь притащить в свой проект либу, вероятность что она содержит CMakeLists.txt (даже если её можно собрать чем-то ещё) значительно выше, чем какой-либо другой системы сборки. По моим наблюдениям среди +- популярных либ доля поддержки CMake две трети или выше. А там где этого нет, это зачастую следствие legacy, если проект большой и серьёзный. Кстати, от него постепенно уходят. Даже Boost уже можно собрать CMake (я проверял, работает).

Все популярные IDE поддерживают CMake, чего не скажешь о других системах сборки. Проект на CMake я могу с одинаковым успехом открыть хоть в Clion, хоть в Visual Studio, хоть в Qt creator. Это из «готовых» IDE. Для IDE-конструкторов типа VSCode тоже есть плагины. Никакая другая система сборки не может похвастаться столь широкой поддержкой. Ты либо обречён писать в блокноте, либо превращать в конструктор любую IDE и не факт, что получится.

Даже для проекта из одного файла CMake неплох, потому что там CMakeLists.txt будет из трех строчек, зато из коробки уметь сборку под разные ОС и компиляторы.

Так в этом и дело. Есть проект, собирается почти два часа сейчас (не слабая тачка). Проект разделен на кучу всего. То есть подпроект, там либо elf либо so с интерфейсом и тесты. Вот ты там что то меняешь и начинают собираться штук 30-50 cpp файлов. А так собиралось бы в разы меньше. Мои проекты тоже из большого числа файлов состоят, но собрать нужно только тест который запускаешь, причем еще два три cpp файла собрать - не проблема, а вот десятки - уже тормозит.

Это нездоровые на голову для мелких и средних проектов включая «привет мир»

Проект уровня «привет мир» на CMake состоит из двух строчек (директивы project и add_executable) и из коробки собирается и GCC, и Clang, и, сюрприз, MSVC (при этом у юзера будет универсальный переключатель отладочной и релизной сборки). А ещё открывается в пару кликов как минимум в трёх популярных IDE - CLion, Qt Creator и Visual Studio без установки неофициальных плагинов. И сразу с работающим автокомплитом и т. п.

Сколько строчек будет в Makefile, чтобы собирать простой проект этими тремя компиляторами? Какое количество телодвижений придётся совершить для нормальной работы с этим проектом в IDE?

А между тем, по мере роста проекта (подключения либ, введение конфигурирования) лучше не станет.

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

Давай, расскажи про сборку буста цмейком :) а то многим «не важно как он собирается», а потом оказывается важно :)

на лично своих хеллоуворлдах

почему хеллоуворлдах?

у меня например такая история. вот написал dsl, оформил в виде либы, там все разеделено было на cpp файлы, boost.spirit попытался спрятать, оно не вылезало никуда, если парсер менялся, то это затрагивало только некоторые файлы. наружу выходил ast, при этом парсер был доступен в тестах самого dsl. потом я заметил что на каждый чих перекомпилирую десяток файлов. сделал все header only и оказалось, что теперь компилирую один файл, котоырй компилировался и раньше, стало быстрее.

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

Гуд фор ю :)

Твое расширение, твои правила :)

Я взял свой пет-проект игрового движка (моя цель - статическая линовка, если что, это обуславливает решения) и сделал git add submodule, а затем add_subdirectory. И смог успешно подключить regex из компилируемых модулей и несколько header only.

При этом оно успешно собирается GCC, Clang и MSVC.

Я не исключаю, что некоторые модули могут не работать, но те что мне нужны - работают.

Куда усложнился?

Проект уровня Hello world по-прежнему состоит из двух строчек (директивы project и add_executable). Сложный проект с большим количеством библиотек и конфигураций сборки будет сложным с любой системой сборки.

Потому что у каждого свои хеллоуворлды.

Вообще все срачи по поводу яп, разбиение на срр/нрр и тд возникают когда ТС пытается свой личный опыт обобщить на весьмир.

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

А B2 там гораздо, гораздо дольше :)

И они существуют

поделитесь пожалуйста :)

Лайфхак - вынести инстацирование всех шаблонов в отдельный обьектник и дальше с ним просто линковаться.

Да, но B2 используется только бустом, а CMake кучей других библиотек. То есть CMake я могу собрать условные две трети популярных библиотек, включая Boost. А B2 могу собрать только Boost. Не видишь тенденцию?

Сложный проект с большим количеством библиотек и конфигураций сборки будет сложным с любой системой сборки.

А простой - простой везде. Типа хелоу ворлд на мейке или баше не в две строчки собирается

свой личный опыт обобщить на весьмир

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

Задачи очень разные, методы их решения тоже очень разные

да на практике оказывается, что примерно все одинаково.

Типа хелоу ворлд на мейке или баше не в две строчки собирается

В две. Только две строчки на cmake дают:

- Инкрементальную сборку с учётом инклюдов (пригодится как только в хеллоуворлд станет больше одного файла)

- Поддержку GCC, Clang, MSVC

- Поддержку выбора режима дебаг/релиз без необходимости помнить опции конкретного компилятора

Это базовые потребности любого проекта с прицелом на кроссплатформенность. И при попытке добавить эти фичи в Makefile или Bash они мгновенно распухнут за пределы этих двух строчек. А это мы только прожиточный минимум организовали и даже не начали подключать библиотеки (подключать, кстати, хотелось бы с адекватными сообщениями об ошибках и, опционально, fallback, так что просто воткнуть `pkg-config --cflags --libs foo` не вариант).

да да, так я и делал. оказалось какой-то лажей. и еще в довесок куча трабл, потому что тебе нужно точно описать что инстанцировать. где-нибудь ошибся и уже ошибка линковки.

на сколько я понял, иногда таким подходом инстанцируется лишнее. ты ждешь пока это скомпилится, а использовать это не будешь.

да на практике оказывается, что примерно все одинаково.

Нет.

А что пояснить? 50+ разрабов генерируют овердохера кода и ещё больше тащат зависимостями. Нужно покрытие тестами, сборка в релиз, сборка в дебаг, сборка с санитайзером, сборка с профилированием, юнит-тестирование, функциональное тестирование, нагрузочное тестирование, упаковка в деб, рпм, в инсталятор, поставка в виде образов виртуальных машин. Сбор метрик с работающей системы, интеграция с графаной-прометеем, дашбордики для менеджеров. Мейкфайла ему хватает :)

Руками Makefile пишут именно что адекваты

Наглухо отбитые неадекваты. У мейкфайлов нет стандарта на оформление. Как мне выбрать что собирать: дебажную или релизную версию. Мейкфайлы про это ничего не знают, а значит каждый писарь может делать как хочешь, а мне придётся читать эти портянки, чтобы найти нужную информацию. Если вообще писарь озаботился разными целями сборки.

В cmake это стандартизировано. Так же cmake позволяет получить информацию о проекте и о ключах компиляции, с которыми собран каждый файл. Это нужно например, чтобы подсветить выключенные блоки ifdef. Или чтобы запустить статический анализ, например clang-tidy. Ты же в своём ответе IDE обошел стороной. Не удивительно, потому что говномейк здесь обтекает по полной.

тащат meson/cmake/

Сложно представить разработчика, у которого на машине нет cmake. Он только передаёт привет миру и никогда не собирал зависимости, которые скорее всего будут на cmake?

Вот для большого или/и сложного проекта да надо уже что-то помощнее.

Для любого проекта. Cmake файл будет короче. Нет никакого смысла собирать привет мир с помощью мейкфайлов, т.к. только сложнее.

Вообще мейкфайлы не нужны даже как выхлоп cmake. Есть ninja.

Ну и дуры, значит, твои IDE

Ты не шаришь. Чтобы правильно проанализировать код нужно знать ключи компиляции. Например для подсветки выключенных блоков ifdef, если дефайны передаются через ключи компиляции. Например NDEBUG.

• Инкрементальную сборку с учётом инклюдов (пригодится как только в хеллоуворлд станет больше одного файла)

• Поддержку GCC, Clang, MSVC

• Поддержку выбора режима дебаг/релиз без необходимости помнить опции конкретного компилятора

это все то, зачем мейк и нужен. и точно так же элементарно реализуется на баше, если сие по вкусу. Честное слово, не понимаю из-за чего сыр-бор. Ну не в две строчки, ну в 5-10, что это меняет? Тем более что это же все реализовано в симейке не в этих двух строчках, а в заранее подготовленных подпрограммах, а тут только вызываются, что мешает на мейке или баше (или вообще любом ЯП) реализовать это в подпрограммах и потом вызывать в две строчки?

Я ниче против симейк не имею, я просто искренне не понимаю зачем он нужен, когда мейк уже есть. Чтоб инкрементальную сборку делать в две строчки вместо 5? Чтоб можно было собирать под разные платформы? Так мейк это умеет опять же из коробки. Разными компиляторами – пожалуйста. Да и ладно бы это сложно и неудобно делалось, так ведь надо осилить концепцию переменной и условия. Куда уж проще?

С библиотеками тоже не вижу проблемы: ты волен сделать это любым из удобных тебе способов, хошь с сообщениями, хошь с проверками, хошь со скачиваниями и сборкой вообще все что хочешь: этож набор консольных команд выстроенный в иерархию зависимостей, а уж как эту иерархию строить, какие зависимости учитывать – все в твоих руках, делай что надо. Чего вам тут может не хватать? Для меня загадка (да и чего не хватает – бери да реализуй как подзадачу, да уже реализовали до тебя, не сомневайся)

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

release_build: build build_deb_package build_mustdie_installer

debug_build: build make_tests send_report_for_managers

build:
  $(CXX) $(FLAGS) .... $(target)

Учу использовать: пишешь make debug_build в каталоге где лежит мейкфайл.

Прости за сарказм, но что из перечисленного не реализуется как набор команд в цели? Я В УПОР НЕ ПОНИМАЮ чем написать набор команд для сборки деб пакета в любой другой системе сборки лучше, набора команд для сборки деб пакета в правиле мейкфайла. Его ж в любом случае писать: или в бестпрактисных системах сборки ты ставишь галочку «хочу виндовый инсталлятор» и оно делает? Нигде описывть не надо, вот прям волшебно само иконку инсталлятору назначает, само триклятое лицензионное соглашение сочиняет?

Мейкфайла ему хватает :)

Во всем этом я вижу тот же мейкфайл, только более своим и менее очевидным образом делающий то же самое. Любой из нас сможет написать свой мейк за вечер, а знаешь почему не пишем? Потому что мейк уже есть.

сборки деб пакета в любой другой системе сборки лучше, набора команд для сборки деб пакета в правиле мейкфайла. Его ж в любом случае писать: или в бестпрактисных системах сборки ты ставишь галочку «хочу виндовый инсталлятор» и оно делает?

Вообще-то да.

В Help написан пример:

cmake_minimum_required(VERSION 3.20)
project(CoolStuff)
add_executable(coolstuff coolstuff.cpp)
install(TARGETS coolstuff RUNTIME DESTINATION bin)
include(CPack)

и вот у тебя есть deb пакет, rpm пакет, инсталлятор CoolStuff-0.1.1-win32.exe и Mac OS X bundle заодно.

Покажи свой Makefile делающий тоже самое, если у тебя есть один файл coolstuff.cpp с твоей программой.

И сравни с этими 5 строчками.

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

Разными компиляторами – пожалуйста

У GCC/Clang и MSVC несовместимые опции компиляции от слова вообще. Даже имя выходного файла задать или уровень оптимизации/наличие отладочной информации.

Вопрос не в том, что это нельзя реализовать на make. Вопрос в том, что там 5 строчек, тут 10, потом ещё что-то добавили. И вот уже на экран не влезает. А мы только начали.

Cmake перестанет влезать на экран позднее. На простых проектах он будет ощутимо проще Makefile, при этом предоставлять прожиточный минимум функционала типа кроссплатформенности и инкрементальной сборки по принципу «просто работает».

Вы не понимаете, почему использовать чужие популярные и отлаженные подпрограммы с кучей документации и примеров вместо своих велосипедов - лучше и для вас, и для гипотетического читателя вашего кода?

Тогда и библиотеки можно не подключать, в целом. Многие алгоритмы реализуются самостоятельно в несколько десятков/сотен строчек. Или это другое?

На счет ccache да, остальное - нет. Вот сейчас по работе один файл изменишь, заголовок, тригирятся штук 50 cpp, а так по кол-ву тестов, в итоге быстрее.

Я не понял откуда быстрее. С хедерами всегда пересобирается весь код, а если у вас несколько бинарников (например, приложение и тесты), то по несколько раз. С cpp код никогда не собирается более одного раза. Если нормально организован проект то на среднестатистический коммит (который таки меняет код, а не интерфейсы, а код лежит в .cpp) пересобирается только изменынные файлы.

Очень редкий случай, когда заголовок поправил и пару файлов пересобралось.

Значит у вас хреново организован проект.

По поводу проверять код - в смысле весь аст доступен, информации больше.

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

Система сборки нужна всегда? Почему?

А как вы собираете код, g++ руками набираете?

Ну и где дашбордики в графану-то?

Примерно вот такое

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

точно так же элементарно реализуется на баше, если сие по вкусу

Нет. Тебе нужно парсить файлы, чтобы достать инклюды и также отслеживать в них изменения. Иначе никакой инкрементальной сборки у тебя нет.

никогда не собирается более одного раза

эм.. как раз наоборот. cpp файлы включают код с помощью include, который они должны, каждый файл, заново собирать. прекомпилинные хереды конечно помогают, но все равно каждый раз одно и тоже. то есть тебе надо собрать один раз проект, а какой-то файл собирается по числу файлов от него зависящих.

Я не понял откуда быстрее

так от туда, что меньше файлов собирать.

среднестатистический коммит (который таки меняет код, а не интерфейсы, а код лежит в .cpp)

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

Значит у вас хреново организован проект.

почему? проекты организованны обычно иерархично, так что смотря где правишь. но даже если какой-то, от которого мало что завсисит, все равно придется несколько перкомпиливать, а не 1.

g++ руками набираете?

vim по f9 запускает build.sh, если это считать системой сборки, то наверное да, всегда :)

эм.. как раз наоборот. cpp файлы включают код с помощью include, который они должны, каждый файл, заново собирать

Ещё раз - они не включают код с помощью include потому что в хедерах кода нет, там только объявления. Их нужно только распарсить.

так от туда, что меньше файлов собирать.

Компилятор компилирует код, а не файлы. Я показал что кода компилируется больше.

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

Любая фича реализуется кодом. А интерфейсы меняются редко.

почему? проекты организованны обычно иерархично, так что смотря где правишь. но даже если какой-то, от которого мало что завсисит, все равно придется несколько перкомпиливать, а не 1.

Если ты изменил один cpp файл то тебе пересобирать один cpp файл. Никогда не два и не три и не тысячу.

vim по f9 запускает build.sh, если это считать системой сборки, то наверное да, всегда :)

Понятно, у вас видимо какое-то своё программирование, где всё зависит от всего и собирается шелл скриптом. Ну тогда вам и хедеры не повредят - лепите как хотите, если думаете что у вас от этого что-то быстрее.

Справедливости ради подход ТС с одной единицей трансляции все же используется https://ru.m.wikipedia.org/wiki/%D0%95%D0%B4%D0%B8%D0%BD%D0%B8%D1%86%D0%B0_%D1%82%D1%80%D0%B0%D0%BD%D1%81%D0%BB%D1%8F%D1%86%D0%B8%D0%B8#:~:text=%D0%92%20%D1%8F%D0%B7%D1%8B%D0%BA%D0%B0%D1%85%20%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D1%8F%20%D0%B5%D0%B4%D0%B8%D0%BD%D0%B8%D1%86%D0%B0%20%D1%82%D1%80%D0%B0%D0%BD%D1%81%D0%BB%D1%8F%D1%86%D0%B8%D0%B8,%3B%20%D0%B2%20%D1%87%D0%B0%D1%81%D1%82%D0%BD%D0%BE%D1%81%D1%82%D0%B8%2C%20%D0%BE%D1%82%D0%BA%D0%BE%D0%BC%D0%BF%D0%B8%D0%BB%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D1%82%D1%8C).

Но недостаток там такой же, как и писали здесь: при малейшем изменении пересобирать все.

Не понял твои тезисы. Но если хочется заморочиться с подходом, то лучше сделай как в sqlite – скрипт конкатенации проекта в один .hpp и один .cpp.

Наглухо отбитые неадекваты.

Не находишь, что это грубовато? У людей отличное от твоего представления о том что правильно и ты называешь их неадекватами

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

И мейк позволяет, представь и даже баш.

Нет никакого смысла собирать привет мир с помощью мейкфайлов, т.к. только сложнее.

Симейк – надстройка над мейком. Что на симейке, что на мейке ХВ собирается двумя строчками. В данном случае симейк можно выкинуть и ниче не измениться, т. е. – упростить ( справедливости ради В ДАННОМ СЛУЧАЕ и мейк-то избыточен и его стоило бы выкинуть :) )

Чтобы правильно проанализировать код нужно знать ключи компиляции. Например для подсветки выключенных блоков ifdef, если дефайны передаются через ключи компиляции. Например NDEBUG.

Проблема яйца выеденного не стоит, как еще бестпрактисты для этого отдельный фреймверк и пакетную систему не изобрели – загадка :)

Смотри, у меня vim и syntastic – плагин к нему для подсветки кода, синтаксических и прочих мелочных ошибок. Как ты справедливо заметил, в некоторых случаях IDE-шке надо передавать параметры компиляции для того чтоб она могла корректно обрабатывать подсветку и проверку. Ну так сборкой же тоже я управляю, я же знаю для каких файлов что передается: просто добавляешь правило для таких файлов в мейк и он создает скрытый(и исключенный из версионного контроля) .syntastic-файлик для этого конкретного сорса, а вим учишь (тоже одной строчкой) подхватывать такой если есть и скармливать синтасику. Две строчки делов. Уверен что более беспрактистные IDE-шки тоже умеют явно принимать параметры для подсветки

или в бестпрактисных системах сборки ты ставишь галочку «хочу виндовый инсталлятор» и оно делает?

Вообще-то да.

И как это работает? Лицензионное соглашение в инсталлятор оно само сочиняет? Иконку? Или это где-то описано в каком-то когнфиге, где-то есть код, который этим занимается и твое «ставишь галочку и оно само делает» на самом деле – вызов подпрограммы? Вопрос риторический. И че, ты думаешь мейк не умеет подпрограммы вызывать? Вопрос тоже риторический. А вот не риторический – разница-то в чем? В том что для симейка уже есть набор готовых подпрограмм? Это что-ли? А что мешает такой для мейка создать?

Покажи свой Makefile делающий тоже самое, если у тебя есть один файл coolstuff.cpp с твоей программой.

Пфф: $(shell build_all_installers_you_want.sh) – умеет даже больше твоего. Ваще все что ни придумаешь – умеет. Вот какой всемогущий мейк, умеющий вызывать внешний код

Вопрос не в том, что это нельзя реализовать на make. Вопрос в том, что там 5 строчек, тут 10, потом ещё что-то добавили. И вот уже на экран не влезает. А мы только начали.

Да что там, что там – есть возможность разбивать задачу на подзадачи. В мейке есть возможность подзадачу добавить зависимостью к какой-то текущей. То есть в конечном счете, это даже не строчка, а просто уникальный идентификатор: короче – некуда. Набор готовых реализаций под все популярные задачи никто не запрещает сделать, никто не запрещает сделать и свою под тонко-настроенную/уникальную задачу. Уверен что в симейке да и любой другой системе сборки – все то же самое. Я просто представить себе не могу как даже теоретически это можно сделать проще, чем

задача1: зависимость1 подзадача1
  действие
  действие

зависимоость1:
  действие
  действие

то есть, по сути, это всего лишь расписывание иерархии зависимостей для выполнения задач, причем настолько простым способом, что проще не придумаешь. А реализация в любом случае – набор команд в конечном счете. И в симейке тоже инсталлятор не по волшебству строится: где-то лежит код с последовательностью действий, не обманывайте что по волшебству, я уверен – код есть

Вы не понимаете, почему использовать чужие популярные и отлаженные подпрограммы с кучей документации и примеров вместо своих велосипедов - лучше и для вас, и для гипотетического читателя вашего кода?

Понимаю. Я не понимаю какая разница между чужими популярными и отлаженными программами на симейке и ЧПОП на мейке? Все те преимущества, которые вы мне описываете родным образом реализуются на мейке, зачем для этого надстройка – в упор не вижу. Если вы мне скажете что так исторически сложилось, что вот такой вот набор ЧПОП образовался на симейке, а так вообще-то никто не мешал сделать то же самое на мейке – то я пойму, в реальзной жизни так постоянно бывает. Но вы же говорите о каких-то преимуществах и начинаете выдавать возможность запуска готовой отлаженной подпрограммы на симейке за преимущество перед мейком. Нет. Нет такого преимущества – все то же самое, мейк тоже так умеет. И даже баш. Просто бери, да реализуй подход

Ну и где дашбордики в графану-то?

Начну с того что дашбордики – суть ерунда, ИМХО. В данном случае. Графана я не знаю что, ну по контексту понятно.

Уверен, что сборшик подготавливает для дашборда данные и дергает за крючок, тогда:

build: ... process_dashboard ...
  ...

process_dashboard: prepare_data pull_grafana_hook

prepare_data:
  $(shell build_xml_for_grafana.sh)

pull_grafana_hook:
  curl $(GRAFANA_HOOK_URL)

ну и тд. в чем проблема-то? Мейк всего лишь описывает иерархию зависимостей для действий. Сами действия если сложнее пары команд и предполагается повторное использование – ну оформи в подпрограмму в том или ином виде. Уверен, у всех остальных сделано так же. ТАк в чем разница и где и для каких случаев мне не хватит мейка?

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

Не вижу проблемы. Симейк сам это умеет или где-то есть код, который, скажем для плюсов это умеет. А для другого языка? А для моего собственного? Если есть подобный модуль для симейка – почему нельзя сдалать его для мейка? Навскидку, добавить правило чтоб бпроходилось по файлу и рекурсивно touch-ило все инклюды, тогда мейк тригернется.

А чем плохо по времени последнего изменения смотреть? Ведь ести инклюд никто не изменял с последнего раза – значит и пересобирать не надо, разве нет? Это – родная функциональность мейка

В том что для симейка уже есть набор готовых подпрограмм? Это что-ли? А что мешает такой для мейка создать?

Да. Опять же менеджер пакетов для C++ есть только для CMake. И много всего есть только для CMake, как поддержка IDE.

В теории могли бы делать и для gmake, но за десятки лет никто не сделал. И всё что есть для CMake реализовать для gmake потребует сотни человеко-лет.

Не уверен что отвечаю на правильное сообщение (оно на момент набора моего тупо оказалось последним).

В чём я уверен though - Вы движетесь в неправильном направлении. Ну, или «за деревьями леса не видите».

CMake vs (GNU) make - погоды не делает. В контексте оригинального вопроса ТС речь нужно вести исключительно о числе «единиц трансляции», и об идиоматическом подходе - «мы режем мелко или крупно». Я сторонник идеи «резать мелко», и жизнеспособность такого подхода подтверждается десятилетиями практического опыта разработки в коллективе из ~1000 сотрудников активно коммитящим в HEAD. И, на самом деле, всё сводится к правильной / оптимальной декомпозиции…

ПыСы. Там кто-то заявлял что готов за вечер «make» реализовать. Смело. Я бы не взялся. И я даже готов ткнуть носом где будут проблемы, и какие фундаментальные задачи придётся решать. Но, это не то что бы мне хотелось обсуждать сегодня…

ПыПыСы. И таки удачи Вам с Вашими проектами: чую одним местом - она Вам пригодится…