До недавних пор не сталкивался серьёзно с CMake. Собирал, конфигурировал — да, но сам почти не писал. И тем более — сложных проектов с нетривиальной сборкой зависимостей. Посмотрел с десяток крупных проектов, таких как ROS, VTK, LLVM, Eigen и так далее, везде какой-то ад и израиль в коде: snake_case, sausage-case и CamelCase в одном файле, разбиение на модули от балды, переопределение стандартных функций и макросов, чтобы сэкономить пару строчек, трёхэтажные if-ы. И всё равно всё ломается. Например, есть опциональная зависимость A, она зависит B, но отключить можно только А. Отключаешь А через -DENABLE_FEATURE=OFF, в каком-то месте нет проверки, что B тоже должна быть отключена, и сборка ломается. Получается, что на собеседовании по С++ могут выдрочить за неправильное название переменной, но когда те же люди пишут конфигурацию сборки, то они резко тупеют и превращаются во вчерашних школьников?

P.S. Единственный проект, который выделяется на фоне всех остальных, это Qt. По нему действительно можно ориентироваться в плане написание конфигураций сборки. Видать за 6 версий разработчики намучились и таки сделали всё по уму

Здравствуйте, cppguard, Вы писали:

CMake — это диавол, сошедший на землю. Но, увы, это почти стандарт

ЗЫ А что такое "sausage-case"? Кебаб, что ли?

Здравствуйте, cppguard, Вы писали:

C>P.S. Единственный проект, который выделяется на фоне всех остальных, это Qt. По нему действительно можно ориентироваться в плане написание конфигураций сборки. Видать за 6 версий разработчики намучились и таки сделали всё по уму

Кстати, Qt до пятой версии включительно использовали свой тул — qmake, но да, я слышал, что они собирались от него отказаться, но 6ой кути не трогал, не знаю

Здравствуйте, cppguard, Вы писали:

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

Одна из главных проблем с CMake лично у меня (кроме кучи других, которые и составляют ДНК CMake) в том, что по CMake нет нормальных обучающих материалов. Даже их официальная документация, местами, оставляет желать много и много лучшего. А вот такого, чтобы описание стадий работы CMake с объяснением что и на какой стадии делается, чтобы возникло более-менее внятное понимание принципов работы CMake, мне пока на глаза не попадалось. Правда, официальную книгу по CMake от Kitware я не покупал -- вот не хочу спонсировать этих говноделов даже косвенно.

То здесь, то там появляются материалы о т.н. Modern CMake, но в каком-то разрозненном виде. Ну и все это еще и "по верхам": для простых проектов OK, но когда приходится копнуть в глубину, то ой.

Поэтому, как я сумел понять, большинство с CMake работает так: берут что-то готовое, что смогли найти, и адаптируют под себя. И хорошо, если это готовое написано в более-менее Modern CMake стиле. Да и адаптируют по своему разумению (а откуда взяться нормальному пониманию, если хороших обучающих материалов нет?) Вот в результате CMake-овских говнокод плодится и размножается.

До недавних пор можно было обходиться и без CMake, посредством собственных систем сборок (qmake тут уже упоминали). Но после того, как в стандарт завезли модули, собственные наколеночные системы сборки, имхо, обречены. Плюс развитие таких инструментов как Conan и vcpkg, куда добавить библиотеку с поддержкой CMake проще, чем с чем-то экзотическим.

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

Здравствуйте, so5team, Вы писали:

S>Одна из главных проблем с CMake лично у меня (кроме кучи других, которые и составляют ДНК CMake) в том, что по CMake нет нормальных обучающих материалов. Даже их официальная документация, местами, оставляет желать много и много лучшего. А вот такого, чтобы описание стадий работы CMake с объяснением что и на какой стадии делается, чтобы возникло более-менее внятное понимание принципов работы CMake, мне пока на глаза не попадалось.
Это не баг это фича, чтобы покупали книгу или заказывали консалтинг.

S>Правда, официальную книгу по CMake от Kitware я не покупал -- вот не хочу спонсировать этих говноделов даже косвенно.
Ну на тебе не сработало

S>То здесь, то там появляются материалы о т.н. Modern CMake, но в каком-то разрозненном виде. Ну и все это еще и "по верхам": для простых проектов OK, но когда приходится копнуть в глубину, то ой.

S>Помочь ситуацию могло бы развитие документации с рассказом о том, как следует применять CMake. Но вряд ли кто-то в это серьезно вложится. Поэтому сейчас вот так, да.
Да уже не надо. ИИ пишет CMake код довольно хорошо и лучше чем 95% программистов. Я еще полгода назад считал эти потом и кровью заработанные знания чем-то относительно ценным, но все. В новых проектах, я руками CMake код больше не пишу

Меня больше удивляют коллеги которые CMake знают плохо, но все равно пишут руками У них проекты с build.sh/build.cmd с вызовом CMake и msbuild внутри

Здравствуйте, cppguard, Вы писали:

Процетирую себя из 2021

Автор: Skorodum
Дата: 09.04.21

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

И еще

Автор: Skorodum
Дата: 27.01.21

1. CMake выглядит как декларативный язык, хотя очень часто от порядка утверждений много что зависит.
2. Документация с довольно странной терминологией.
3. Двухэтапная сборка.
4. Тонны устаревших ответов на простейшие вопросы.
5. Отсутствие каких-либо стандартов форматирования помноженное на смешанную политику отношения к регистрам ("где-то регистр различаю, где-то нет").

Но сейчас ИИ таки решает эти проблемы лучше, чем 95% разработчиков.

C>P.S. Единственный проект, который выделяется на фоне всех остальных, это Qt. По нему действительно можно ориентироваться в плане написание конфигураций сборки. Видать за 6 версий разработчики намучились и таки сделали всё по уму
Конечно: помимо кроссплатформенной библиотеки они 2 своих системы сборки и IDE написали

Здравствуйте, cppguard, Вы писали:

C>Получается, что на собеседовании по С++ могут выдрочить за неправильное название переменной, но когда те же люди пишут конфигурацию сборки, то они резко тупеют и превращаются во вчерашних школьников?
В сложных проектах билд система должна поддерживаться отдельным человеком (а лучше хотя бы парой). Наружу из нее должен торчать простой и понятный для школьников интерфейс для ее настройки чтобы "те же люди" не ломали себе голову. Интерфейс должен быть заточен под конкретный проект. Но такое есть чуть более чем нигде. Потому что:
— мало кто умеет сделать нормальную билд систему поверх CMake, Gradle, GNU Make и т.п.
— мало кто хочет этим заниматься, потому что это абсолютно неблагодарное занятие.
— мало кто готов выделить целого инженера для этой работы.

C>P.S. Единственный проект, который выделяется на фоне всех остальных, это Qt. По нему действительно можно ориентироваться в плане написание конфигураций сборки. Видать за 6 версий разработчики намучились и таки сделали всё по уму
У них, скорее всего, просто есть отдельный человек, который знает как писать эти конфиги, обьяснил остальным как это делать, и ревьют все их изменения.

Здравствуйте, Skorodum, Вы писали:

S>Но сейчас ИИ таки решает эти проблемы лучше, чем 95% разработчиков.
Это до очередного обновления CMake, когда свежие ответы на SO, на которых тренировался ИИ, устареют. А новых не будет, потому что кто ж сейчас пишет в SO, если ИИшечка есть под рукой. Замкнутый круг

Здравствуйте, alsemm, Вы писали:

A>Это до очередного обновления CMake, когда свежие ответы на SO, на которых тренировался ИИ, устареют. А новых не будет, потому что кто ж сейчас пишет в SO, если ИИшечка есть под рукой. Замкнутый круг
Это популярная теория для всех языков и фреймворков, но я не уверен, что она верная. У меня нет сильных аргументов, только такие:
* вряд ли будут какие-то сильно кардинальные изменения в CMake. "Оно работает".
* будут выживать технологии которые дружественны к ИИ или по которым достаточно знаний, поэтому разраработчики CMake мотивированы документировать измения так, что этого должно быть достаточно для для тренировки ИИ.

Здравствуйте, Skorodum, Вы писали:

S>Но сейчас ИИ таки решает эти проблемы лучше, чем 95% разработчиков.

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

Сам инструмент очень проблемный.
Постоянно меняют поведение, функции, интерфейсы.
Иди за всем успей.

И это не говоря про синтаксис, где очень легко ошибиться:

Плохо:

add_executable(myapp "${SRC_FILES}")
set(MY_LIST ${MY_LIST} new_item)
set(MY_LIST "hello world" foo)

Хорошо

add_executable(myapp ${SRC_FILES})
list(APPEND MY_LIST new_item)
set(MY_LIST "hello world" "foo")