За что так не любят cmake?

Почему-то всякое упоминание cmake притягивает толпу разъярённых людей. Чем он так плох?

Фу кака. Сборка с загогулинами, статической линковки у программ на нём не заметно, а если и есть, то запрятана. Какая-то дрянь для потребностей плюсовиндузятников.

Немного упоротый синтаксис, есть заморочки с кастомными таргетами, и прежде чем научишься структурировать более или менее сложный проект раз пять сделаешь фигню. Некоторые генераторы, особенно под визуал студию, поддерживают не все фичи. Проблемы заставить работать с долбанутыми компиляторами с нестандартными флажками командной строки. Да и в принципе cmake проект очень сложный и фичастый с большим порогом вхождения. За это и не любят. А плюсы - в разы адекватнее автолулзов, очень хорошая обратная совместимость и намного проще чем в случае автолулзов собирать ещё и под венду/мак и искать на этих убогих платформах без pkg-config'а библиотеки. Ну и генератор проектов для студии и xcode позволяет автоматом отсатисфачить инвалидов, ежели таковые есть в проекте/среди потребителей. Очень хорошие инструменты для паковки и тестирования.

Как-то так.

Не самый худший синтаксис

Немного упоротый синтаксис

Можно пример?

Проблемы заставить работать с долбанутыми компиляторами с нестандартными флажками командной строки.

В чём проблемы? Автоматически подставляет GCC-шные ключи?

автолулзов

Хорошее название :)

в разы адекватнее автолулзов

Можно тоже пример неадекватности?

статической линковки у программ на нём не заметно, а если и есть, то запрятана

Конечно, незаметно. Линковкой занимается линкер, а какие передать ему редкие ключи — твоё дело. Ключи здесь: https://gcc.gnu.org/onlinedocs/gcc/Link-Options.html

Таки есть она - premake - https://github.com/premake/premake-core/wiki/What-Is-Premake

Есть статистика его распространённости?

В числе форкавших нашёл Blizzard. Внушает.

Куча легаси

Можно примеры?

упоротый синтаксис.

В чём заключается упоротость?

Вообще-то, 500 против 1500. Втрое.

а еще он из коробки может работать с conan: https://docs.conan.io/en/latest/integrations/cmake.html

А что такое conan? Какие у него преимущества перед теми же apt-dpkg или rpm с чем-то ещё? Сколько пакетов в его хранилищах?

И я считаю CMake это худший вариант из тысяч возможных.

Что вместо него?

когда ... из альтернатив были только autotools, про которые те же windows люди вообще не слыхивали,

ЕМНИП, в те времена было принято в тарбол класть 2 файла: makefile и Makefile. Кто кого затирал или кому на что меняли имя — труднопредсказуемо :)

Я почти уверен, что он скажет «тег на гитхабе». Потому что не знает, что github'овые тарболы генерятся при скачивании, и github уже не один раз менял алгоритм генерации, в результате чего у тарболов ВНЕЗАПНО становятся разные SHA256 суммы, что доставляет мейнтейнерам.

Для этого сделали «релизы».

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

kconfig-стайл

Кто его использует помимо ядра?

Но сложное прикладное ПО имеет особенность становиться кросс-платформенным со временем.

Верно.

Линковкой занимается линкер, а какие передать ему редкие ключи — твоё дело.

Круто, от программиста уже не зависит, какое ПО он пишет, статическое или динамическое, ни о чём париться не надо - линкер нам поможет!

target_link_libraries(app ${SOME_LIBS_VARIABLE} -lm -lpthreads)
Что будет, если SOME_LIBS_VARIABLE не будет существовать? CMake скажет, что ты обращаешься к несуществующей переменной? Ничего подобного. Молча прожует и ничего не скажет.

Кто ведёт себя иначе? Помимо скриптов на Питоне.

2) Кэш.
$ cmake . -DSDL=yes && make
$ cmake . -DHEADLESS=yes && make
CMake за счёт кэша будет считать, что SDL должен равняться YES и даже во втором вызове.

Как лечить? clean каждый раз?

3) Синтаксис
Вызов функции здорового человека: f( x, y, z )
Вызов функции курильщиков из Kitware: f(x y z)
Проблема-то в чём? Неизвестно как закончить выражение и опять же см. пункт №1. Для этого курильщики из Kitware предлагают в функции парсер аргументов и вызов будет выглядеть так f(ARG1 x ARG2 y ARG3 y).

Как бы решил проблему ты? Изменил обработку запятой?

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

Кроме gcc последней версии в мире нет компиляторов и question4 пиарменеджер его;)

Я бы не стал придумывать наркоманский язык.

Лечить легко: rm -rf build. Это единственный вариант вразумить CMake. clean не работает.

Ведут себя иначе все. Ну кроме шелла и мейка, про них я уже сказал.

U-Boot и Busybox. Вроде что-то ещё, но я не помню.

Попроси кого-нибудь рядом с тобой зачитать тебе мой комментарий.

Юзая системы типа конана у тебя получается дистронезависимый билд, где все зависимости описаны одним блоком в текстовом файле, и итоговый пакет с софтом может билдиться способом «всё своё тащу с собой». Примерно как Maven в Java или Npm в JS. Зависимости локальны по отношению к проекту, не нужно загаживать зависимостями базовую систему - ни тебе, ни конечному пользователю.

И нужно пересобирать все пакеты при обновлении зависимости. Красота!

Не нужно, зачем. Так и будет там статически влинкована старая.

Не нужно, зачем. Так и будет там статически влинкована старая.

Да, в этом-то и проблема :))

Можно пример?

возвращение переменных через передачу аргументом функции, скоупы, if() else() endif(). Не всегда однозначные для новичков правила раскрытия переменных под if(). Не то чтобы были фатальными недостатками, но новичков это все выбешивает, почитай нытье ниосилятором в этом самом треде.

В чём проблемы? Автоматически подставляет GCC-шные ключи?

А если это компилятор для DSP, и ключи у него ни разу на gcc не похожи? Особенно, когда дело касается линковки библиотек.

Можно тоже пример неадекватности?

На винде/маке боль, out-of-directory сборки не всегда отрабатывают как ожидается и их поддержка до сих пор не стандарт де-факто, нет поддержки генерации проекта для инвалидов-фанатиков eclipse/VS/code::blocks, с кросс-компиляцией и pkg-config дикая боль. Дико медленный этап configure, нет поддержки ninja, обратная совместимость по опыту так себе. Это все что вспомнил с ходу. Автолулзы для своих проектов уже не использовал лет 7-8.

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

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

Почему-то всякое упоминание cmake притягивает толпу разъярённых людей

Неосиляторы-с. Синтаксис им, видите ли, непривычный. Хотят небось m4, ибо большинство (на самом-то деле всего их не много, но орут громко) - недовымершие autocrap'щики. Или питон, ибо история SCons ничему не научила. А на самом деле синтаксис для билд системы просто идеальный. Другая претензия - то что CMake не хотят бандлить Find* модули для всех существующих библиотек, вместо этих самых библиотек. Всё это говорит только о компетентности этих людей.

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

/me бурчит и лезет обратно в криокамеру.

В таком случае уже без разницы. Что угодно лучше, чем GNU Autohell.

Систему сборки с синтаксисом lua было бы неплохо.

Premake же есть.

Другая претензия - то что CMake не хотят бандлить Find* модули для всех существующих библиотек, вместо этих самых библиотек. Всё это говорит только о компетентности этих людей.

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

В итоге в любом сколько-нибудь сложном проекте со сборочной системой CMake разработчики греют голову о четырёх наборах разных Find-модулей:

1. Заскорузлая херня из дистрибутива CMake.
2. Модули разработчиков либ, которые прогнулись под требования быдлокодеров из Kitware и начали распространять FindModules.
3. Модули для либ, разработчики которых срать хотели на CMake, натыренные из интернета.
4. Cамописные кривые модули от полуразобравшихся в угрёбищном DSL CMake'а программистов.

Кто мне скажет, какой Find-Module правильный? Может быть ты? Гы.

1. FindSDL2_mixer.cmake
2. FindSDL2_mixer.cmake
3. FindSDL2_mixer.cmake
4. FindSDL2_mixer.cmake
5. FindSDL2_mixer.cmake

Тысячи их и все полурабочие и кривые. Потому что нормально сделанные мудаки из Kitware теперь отвергают: https://github.com/Kitware/CMake/pull/152

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

Все как идиоты и виндузятники сегодня рыщут по интернету/гитхабу с огромным мешком и складывают в него полупротухшие CMake-модули, либо пишут своё полурабочее говно.

Это ты называешь компетенцией и дальновидностью эти людей?

[CMake Code Monkey #1]: Смотрите на нашу новую сборочную систему CMake, мы написали кучу Find-модулей к популярным библиотекам и заботливо положили их в папочку дистрибутива программы! Разработчикам библиотек больше не нужно думать о написании этих модулей, а разработчикам программ не нужно писать их самостоятельно. Yay!

... прошло три года ...

[CMake Code Monkey #2]: Блин, с этими Find-модулями куча проблем! У нас не хватает рук и вообще мы маленькая компания. Что-то срочно надо делать. Давайте переложим работу по написанию Find-модулей на разработчиков библиотек! А что делать с уже написанными нами Find-модулями? Давайте их заморозим нахер и будем таскать мёртвым грузом за собой всегда! Пок-пок-пок!

... прошло два года ...

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

Ссаной тряпкой по лицу идиотам из Kitware. Когда кто-то говорит о CMake и об поиске зависимостей, у адекватных людей это должно вызывать лишь громкий хохот, переходящий в истерику. Потому что хуже эту функциональность сделать ну просто невозможно! Лучше бы её вообще не было.

в его безальтернативности на текущий момент.

Да. Как часто это бывает, случилось так, что в IT снова победило самое херовоспроектированное, неочевидное, нелогичное и убогое говно под названием CMake.

К сожалению ты прав. CMake сегодня безальтернативен. Но он не перестаёт быть от этого говном.

Red Hat начал уходить с него и автокрапа на Meson. Перевёл все свои проекты вроде пульсы, Wayland, Systemd и весь GNOME на него. Перевёл иксы и ещё парочку значимых в мире Linux проектов. Но теперь, когда RH куплен IBM'ом хрен его знает будет ли он продолжать разрабатывать Meson.

Как часто это бывает,

вы - очередной неосилятор, который даже этого не стесняется.

GNU Make прекрасно работает в винде, например.

К сожалению, это не так. Многопоточная сборка с его помощью превращается в Ад по скорости. Что там у винды? Медленный аналог fork()'а — CreateProcess() который активно юзает make? Всех подробностей я не знаю, но make в несколько раз медленее работает в винде, чем любом Linux'е или macOS.

Проблема перед крупными проектами стояла так остро, что они даже начали пилить собственные аналоги make, например, Qt-разработчики сделали jom, а Google-разработчики — ninja.

Этот, прошлые и все последующие треды про CMake только потдверждают то, что с этой хернёй что-то не так.

Так что касательно ответа на вопрос, наш уважаемый ыксперд CMake и осилятор? Какой из тысячи FindModul'ей библиотеки SDL2_mixer ты бы выбрал на GitHub'е? Или может быть написал его сам, да так чтобы он получился у тебя кросс-платформенным, ха?

Логично что если автор библиотеки не написал модуля, то его придётся бандлить всем пользователям. И они бандлят. И всё работает. Потому что в модуле этом три строчки find_file, find_library и mark_as_advanced. В некоторых случаях ещё хинты от pkgconfig, если не лень. Больше ничего и не нужно, это здоровая замечательно работающая экосистема.

...в отличие от autocrap'а (который не работал без указания -I/-L в CPPFLAGS/LDFLAGS, и при этом всегда всё ломалось, потому что эти флаги попадали в аргументы компилятора и линковщика до локальных, и при сборке библиотеки начинали подцеплять ошмётки своих старых версий из системы), и других смузи-систем где работающего поиска зависимостей нет вообще.

Этот, прошлые и все последующие треды про CMake только потдверждают то, что с этой хернёй что-то не так

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

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

Лол. Ну иди и собери проект, в котором в одном из кривонаписанных тягаемых с собой модулей внезапно забыли про поддержку macOS или MS Windows. Или даже Linux (такое тоже бывает, лол).

В случае если бы Kitware не были обмудками, они бы бандлили и сопровождали модули. Либо сделали официальный репозиторий для того, чтобы сообщество могло разрабатывать и сопровождать модули к библиотекам, которые срать хотели на CMake. Раз сами они не в состоянии.

есть один упорный ненавистник

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

Как лечить? clean каждый раз?

mkdir build_sdl ; cd build_sdl
cmake .. -DSDL=yes
cd ..
mkdir build_headless ; cd build_headless
cmake .. -DHEADLESS=yes

Kitware'овцы настаивают на таком подходе.

Самый простой вопрос: есть либа, которая называется, ну например, dosomething. Как средствами CMake узнать, во что он превратит её название на целевой платформе?

Правильный ответ: см. в правках.

Многопоточная сборка с его помощью превращается в Ад по скорости.

Разумное соображение. Что-то я не подумал.

Не так давно вылезла проблема с кросс-компиляцией. В проекте использовался генерируемый исходник на C, и генератор для него тоже был написан на C. Пока не стали заморачиваться с кросс-компиляцией для arm, все работало отлично. А как понадобилась кросс-компиляция, выяснилось, что документированного способа сказать «вот этот исходник компилируй не кросс-компилятором, а обычным» просто не существует. И пример с генератором из официального tutorial'а имеет ровно ту же проблему - не поддается кросс-компиляции.

Решение таки нашел: вынести генератор в отдельный проект в поддиректории, добавить его к основному проекту через ExternalProject_Add, импортировать бинарный файл генератора через add_executable(generator IMPORTED) и установку свойства IMPORTED_LOCATION. Но такое должно быть в документации, а не в архивах списка рассылки!!!

В итоге мое решение не приняли, а переписали генератор на Perl'е. В общем-то согласен: получилось понятнее.

Респект мезоновцам: у них этот пример разобран по полочкам в очевидном месте (http://mesonbuild.com/Cross-compilation.html#mixing-host-and-build-targets).