Вышла новая версия CMake 3.16.0

Годные изменения.

Где на этот cmake вменяемый туториал найти? Желательно, чтобы он не фокусировался на C, а чтоб о том, как собирать многоязычный проект с адскими зависимостями.

где бы почитать про target_precompile_headers() и UNITY_BUILD с примерами

По своему опыту скажу, что лучше не находить. Да, CMake становится лучше, документация у него наконец-то появилась, старые неудачные решения потихоньку выкидывают и именно поэтому я написал новость, но у него всё ещё упоротый DSL. И я просто не хочу тратить на него своё время и не советую другим, если у вас нет существующего проекта с CMake.

I_one, в документации. Добавлю ссылки в новость.

А что с альтернативами? meson?

А то qmake закапывают в пользу cmake - ищу куда бежать. Ибо лучше смерть, чем cmake.

Qbs хоть и перестал Qt-эшниками поддерживаться, но его всё ещё развивают.

Я развиваю для себя форк waf со всякими расширениями, которые наврядли примет автор, но то что может – засылаю обратно.

А так, meson лучшая альтернатива на сегодняшний день. Подчеркну, что альтернатива, поскольку тоже является генератором со своим DSL, но всё же более удачным. :)

Ну свой форк системы сборки - это слишком. Тем более такой редкой (я waf встречал только у mpv).

PS: за имя +

На самом деле, времени отнимает даже меньше, чем сколько пытаешься побороть очередную проблему CMake. Тем более в условиях, когда проблема со сборкой у тебя не воспроизводится. А waf не имеет зависимостей кроме Python и вообще распространяется вместе с исходным кодом, поэтому проблема однозначно в кривизне рук либо твоей, либо того кто собирает. :)

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

Имя хорошее, но оказывается я не один такой. :)

И я просто не хочу тратить на него своё время и не советую другим, если у вас нет существующего проекта с CMake.

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

А что с альтернативами? meson?

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

При всех своих проблемах больше всего распространены только cmake и autotools. Все остальные - экзотика. Новые появляются и исчезают, эти пока остаются.

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

а месон - г-но, кстати.

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

А зачем луа когда питон есть почти в любой системе?
meson действительно так себе, ещё и ninja требует

нормальный у него дсл, в стиле баш-скриптов

Спасибо, не надо.

А я уже пользуюсь этой версией с выхода версии RC.

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

Ага, именно поэтому мы имеем это: https://github.com/onqtam/awesome-cmake#examples--templates

Ну и cmake ни разу не простой. У него сорцы почти четверть ляма.

Простой - это cargo.

A curated list

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

Предлагаю высказать «cmake это просто, если ты не пилишь на нём говнокод в 1000 строк» в /usr/share/cmake/Modules. А это между прочим пишут те же люди, что и сам CMake.

При всех своих проблемах больше всего распространены только cmake и autotools.

Ну вот meson это понимают и сделали cmake subprojects. Оно запускает сборку cmake (можно передавать параметры), парсит AST и строит по нему свой subproject.

Пробовал. Если нет зависимостей от custom_target-ов, и нет внутренних зависимостей то, в принципе, оно неплохо работает. Как минимум избавляет от необходимости переписывать сборку библиотек-сабпроджектов (ну или обходиться минимальными правками CMakeLists.txt)

/usr/share/cmake/Modules

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

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

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

Кстати. Может кто поделится мыслями. Будут ли документированы функции команды file (RPATH_CHANGE, RPATH_CHECK, RPATH_REMOVE, READ_ELF)?

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

А как же карго? Или ты не только на растишке катаешь?

Довести бы до ума https://shakebuild.com/ - хорошая задумка, только вкурить сходу сложно. Или у меня руки из зопы растут…

Ты всегда можешь нести самописные требуемые тебе модули вместе с проектом.

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

Проблема только в том, что без этих модулей CMake ничего из себя не представляет. Ни тебе ExternalProject, ни CMakeDependentOption, ни CheckЧтонибудь, ни лапши из Find*, которую героически Kitware пытались писать, но походу потихоньку забивают.

а мне норм. монорепозиторий решает большинство «проблем симейка». не использую ни external, ни check, ни find, рад за всех кто там что-то переписывает или не переписывает, всем желаю удачи и машу рукой.

Ну, похвально тогда. А ты можешь показать что за проект или он не открыт? Не троллинга ради, я прекрасно понял о чём ты. Просто интересно.

Если очень-очень хочется python, то есть SCons. Но в нём,как минимум, есть свои заморочки с передачей ему переменных окружения - в некоторых случаях то ещё удовольствие. То есть по умолчанию он о них ничего не знает, имитируя «изолированную» среду.

Автор Waf и вдохновлялся отчасти SCons. Вроде даже какие-то первые версии, когда проект ещё не имел такого названия, имели что-то общее с SCons. Но в итоге, проект не имеет к нему никакого отношения.

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

Эх, а ведь waf мог бы использоваться проектом kde, но не успел. Но пишут, что он лучше для крупных проектов, чем SCons, который более популярен в научных проектах.

Какой же мерзотный этот CMake. Каждый раз, как с ним сталкиваешься, хочется вымыть руки с мылом.

Скоро он займёт почетное звание заменителя умирающего autotools по степени упоротости.

И ведь есть же в этом мире более удачные системы сборки, которые приятно использовать: Meson, Waf, QBS и какой-нибудь там Premake. Но нет, выиграет всеобщее использование обязательно самая мразотная и ублюдочная сборочная система. Что раньше autotools, что сейчас CMake.

cmake говно, юзайте meson

Я и на плюсах/Qt пишу.

Это удел линуксов и систем сборок. Но у autotools есть одно преимущество перед cmake - его можно запустить где угодно где есть sh и make. В то время как cmake придётся бутстрапить

CMake это если я правильно понял утилита для конфигурирования генерации конфигурации для make, который конфигурирует билд, с правильными опциями конфигурации. Чтобы все было полностью сконфигурировано. Конфигурировать можно бесконечно, сколько душа пожелает

Вспоминается xkcd про стандарты.

Уже был питонорождённый scons, теперь у нас питонорождённый meson.
Потом ещё какую-нибудь новую хрень придумают на питоне.
И апологеты новинки будут бегать и кричать, что всё остальное говно, юзайте *super_fkn_new_build_system_name*.

Вроде можно обмазаться еще на уровень выше и юзать Conan для генерации CMake говна.

Надо бы еще https://bazel.build/ потыкать.

Я если что просто мимопроходил.

Нет. Cmake может генерить не только для различных make'ов или ninja файлы, но и файлы проектов для VS, XCode etc.

Так всё правильно. Что CMake, что meson - это утилиты на замену autotools. Сборка как была за make/ninja так и осталась.

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

Я вот даже не знаю какая он замена. Как по мне говно говном, как и autotools. Как и вся эта экосистема

единственный существенный плюс - отсутствие поддержки всякого ископаемого и поддержка основных ос - Win32 Mac Linux BSD

Сборку проекта любой сложности проще описать сразу в Makefile чем возиться с CMake. Хотя если не использовать своих модулей которые придётся таскать с собой то он удобен, наверное. Короче, сколько лет его знаю так я его и не понял :D

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

meson проект на смести Fortran77 Fortran90 и c соберет?

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

С поддержкой модулей и остальных костылей.

Все могут, а С++ не может. Я думаю ерунда, надо начать делать.

пакетный менеджер нужно делать частью языка

Ду-у-умаешь?.. меня почему-то не покидает ощущение какой-то наколеночности и нубскости этого подхода. Я один такой? Все эти нпмы и пипы. Преимущества есть, не спорю, но нутру всё равно не нравится. Мб это потому, что долгое время писал на сях.