CMake 3.28

Так сколько лет тому мезону?

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

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

Поддерживаю. Если вы всего пару лет назад, с гигантским трудом, переползли с автотулзов на симейк, и вас всё устраивает, то меньше всего вам сейчас хочется испытать это всё по-новой. :)

Мезон - он и сам новый, и для новых проектов делается.

Тогда может кто макрос на m4 для автоконфа написал :)

Ну чтобы несколько сотен файлов и с поддержкой инкрементальной сборки. Боюсь представить размер makefile портянки и её сложность поддержки

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

А если нету ни в cmake ни пкгконфиг?

Тогда такую либу надо закопать по причине «obsolete, unmaintained crap», и написать новую.

Так мезон же все равно опирается на модули от cmake и pkg-config. Какой у него есть свой инструмент для dependence discovery?

Зачем ему свой, спрашиваю я в стопятисотый раз. :) И хватит говорить, что он на модули симейк опирается. Сделали костыль для инвалидов, так вы и рады. На пкгконф он опирается, и генерит их сам для вас заодно.

Всё остальное компилится примерно единообразно, а отличия между системами по месту делаются ifdef-ами и небольшим набором конфигов компиляции

А либы искать тоже ифдефами? А кросс-компиляторы?

По синтаксису cmake удобнее

Ага. Особенно f(x y z) и f(ARG1 x ARG2 y ARG3 y)

Вообще касательно критики синтаксиса и поведения CMake был хороший и конструктивный пост от бывшего разработчика ЛОРа тут: За что так не любят cmake? (комментарий), он вёл свой далеко не хеллоуворлдный кросс-платформенный (Linux, Windows, macOS, Android, *BSD, Haiku и пр.) проект и наелся корявой CMake-архитектуры вдоволь. Папочка cmake с костыльками там тоже нехило разрослась и в итоге одним прекрасным днём они ушли с CMake и возвращаться не планируют.

Причём тут либы?

Во-первых, по-нормальному - либы должны указываться в виде -llibname и они либо есть, либо их нет, «искать» будет компилятор. Да, pkgconf тоже не нужно.

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

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

был хороший и конструктивный пост от бывшего разработчика ЛОРа

Так он же забанен.

Ну от этого коммент не перестает быть конструктивным, кстати.

Уже нет, он зарегистрировался снова.

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

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

А вам известно, сколько подводных камней вылазит при портировании на андроидный бионик, например? Там, банально, нет позиксовых функций! Вот вы смеётесь над поиском принтфов, а в бионике нет, к примеру, pthread_cancel() в либптрид, и много чего ещё тупо нет. В каком-нить там цигвине, и то больше позикса, чем в бионике. Посмотрю я на ваших юзеров, которые будут пытаться собрать там ваш говнокод мейком.

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

Так он же забанен.

Он сменил ник просто.

…личина autotools’ов, просто в гламурной обёртке…

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

Почему портянки то?

/usr/bin/ld: cannot find -lsomelib

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

pthread_cancel

Я не отрицал что некоторые функции надо проверять. Даже на нормальных x86 системах не везде могут присутствовать такие обычные вещи как strlcpy() или explicit_bzero(). Но, опять же, это примитивная операция, явно не повод городить монстра как cmake. А так же не повод проверять то, что было актуально 40 лет назад, или то, что проекту не нужно, как делают автотулзы.

Ах, если бы в гламурной. Только на голову больной мог придумать такой синтаксис,

Да. Гламурная обёртка это вот эти вот картинки на их сайте и лендинги. А синтаксис там адовый. Создателям синтаксиса CMake точно подготовлен отдельный котёл в аду.

Я вот даже навскидку вообще не смогу назвать БОЛЕЕ худший DSL, чем тот что реализован в CMake. Он собрал буквально все недостатки самой разной скриптоты, начиная от виндовой регистронезависимости которая превращает любую кодовую базу в помойку и заканчивая вот этими приколами с функциями и неопределёнными переменными.

Я вот даже навскидку вообще не смогу назвать БОЛЕЕ худший DSL

Brainfuck и Malbolge подойдут?

Говно, не нужно.

что тут непонятного?

А это что, по вашему, единственный пример? А если просто андефайнед символы валом попёрли? А оказалось, что апстрим разделил либу на 2, и надо теперь с обеими линковаться? При чём, нормальный человек бы даже не заметил, ведь соответствующее изменение прилетело и в её .pc-файл тоже. Все, кто сидел на нормальных системах сборки - ничего не заметили, а мейк - рассыпался. Юзеру за это отдуваться?

А как на счёт опциональных зависимостей? Например, ну нету такой либы на данной системе, и поставить нельзя. «Отключить бы… но нет… у меня рукоядки такой» :)

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

Да не, сам напишу скрипты, чо! :) «существование файлов по списку», ага, а в каком префиксе искать будете? На линуксе они в /usr, на бсде - в /usr/local. Ага: я заведу список потенциальных локейшнов, и буду по нему пробегаться… Ну и тд. :)

Даже на нормальных x86 системах не везде могут присутствовать такие обычные вещи как strlcpy()

Ну тоже, кстати. Где-то для неё надо делать -lbsd, а где-то и нет. И как быть?

явно не повод городить монстра как cmake

Да никто и не предлагает cmake! Мезоном пользуйтесь, 21 век на дворе.

бывшего разработчика ЛОРа тут

Не надо, ЛОР я не разрабатывал xD

Инкрементальная сборка там автоматом получается.

Не получается. Чтобы была инкрементальная сборка нужно парсить директивы include, чтобы узнать от чего файл зависит. Иначе тебе придётся вручную этот граф прописывать в мейкфайлах и это помимо обычных зависимостей между объектными файлами. А без этого можешь попасть в wtf ситуацию когда у тебя часть объектников не пересоберётся и программа будет не консистентной.

Brainfuck и Malbolge подойдут?

Если бы CMake был эзотерикой он бы ещё с ними посоперничал. В Brainfuck хотя бы есть лаконичность, есть свой стиль. А что есть в убогом DSL у CMake который спроектирован тяп-ляп методом?

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

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

А как на счёт опциональных зависимостей?

make вполне поддерживает приём аргументов, влияющих на процесс сборки.

в каком префиксе искать будете?

Искать будет компилятор, там же где и ищет при сборке. gcc -print-search-dirs Вручную никакие списки префиксов хардкодить не нужно, и их намного больше чем ты предложил.

Мезоном пользуйтесь, 21 век на дворе.

Ставить питон чтоб потом собирать проги на Си это бред.

Это, кстати, действительно так. Хотя я и согласен с позицией firkax, я бы не сказал что писать портянки на Makefile чем-то лучше.

К сожалению, в этом мире существуют и другие компиляторы кроме GCC и Clang. Я на днях ускорил сборку включив (уже готовый, правда) модуль использующий компилятор для вычисления зависимостей вместо использования встроенного, который написан на Python и соответствующе питону тормозит.

Несмотря на то, что это прекрасно работает с GCC и Clang, потому что там есть специальный флаг генерирующий зависимости в синтаксисе Makefile, аналогичного флага у MSVC не существует. Самое близкое это /showIncludes, который невозможно распарсить, если системным языком стоит что-то отличное от английского языка. Собственный готовый модуль реализующий это для MSVC не учитывает ничего кроме английского.

Я проверил что делает любимая симейком и мезоном ниндзя и… у них тоже нет решения. Максимум, что можно сделать – заранее передать альтернативную строчку, что возможно и делает CMake и Meson при генерации ниндзяфайла.

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

Да. После того как проект (особенно кросс-платформенный) набирает массу его разрабочики становятся перед выбором:

• Оставаться на CMake, раздувая папочку cmake кривыми/косыми костылями с ущербным синтаксисом.
• Уйти с CMake на более конфигурируемые системы сборки, которые позволят им писать подобные велосипедики (раз уж у них сложная сборка), но уже удобно и на полноценном ЯП по типу Lua, JavaScript, Python вместо CMake-кастрата.

Ставить питон чтоб потом собирать проги на Си это бред.

Не такой уж и бред. Почти на каждой *nix-like системе Python хоть какой-то версии уже установлен. На Windows его можно установить хоть с оффсайта, хоть с их недорепозитория/аппстора.

Этим и понравился waf. Работает он вплоть со самых старых легаси версий по самые современные. И ещё чтобы не делать pip install, который кстати опасно делать в Linux дистрибутивах, так как он (аналогично make install какой-то рандомной программы) превращает систему в Slackware, а venv на каждый чих создавать – это такое. =/

Ну да ладно, я всё равно уже написал как pkgconf использовать без блоатварных сборщиков.

Привожу цитату: «Ну ладно, если без pkgconf тебе никак - можно его запустить пару раз перед сборкой хоть бы шелл-скриптом (сгенерировать переменные окружения для мейка) и дальше никаких проблем.» - то есть, мы руками, на основе пкгконфига, генерим Makefile.conf? А потом ещё вы ифдефами предлагали обкладываться, то есть и config.h мы тоже генерим, верно? Ну, видимо, лет 40 назад автотулзы примерно так и зарождались. :)

make вполне поддерживает приём аргументов, влияющих на процесс сборки.

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

Искать будет компилятор, там же где и ищет при сборке.

Так вы ж сами предлагали, перед сборкой, всё ж скриптиком поискать что-нибудь, хотя бы хедера… А теперь снова компилятор? :)

Ставить питон чтоб потом собирать проги на Си это бред.

Ну вот народ нашёл какой-то muon-meson, который пистона не требует. Правда и функционал последних мезонов он не даёт.

/showIncludes, который невозможно распарсить, если системным языком стоит что-то отличное от английского языка

Как же не хватает банального LANG=C, да? С виндой вообще много сложностей. Кстати /sourceDependencies не подойдёт?

Вижу тут его советовали:

https://github.com/ninja-build/ninja/issues/1766

Но там у вас поди ещё VC++6 не отпускает? D:

а venv на каждый чих создавать – это такое. =/

А pipx?

А для мезона кто о таком озаботился?

У мезона есть мега-фича специально для таких заботящихся.

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

Уже давно отпустил, можно запиливать. Потом в апстрим заслать :)

Хм! Не слышал о таком, спасибо за наводку.

pip install

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

Ну, видимо, лет 40 назад автотулзы примерно так и зарождались.

Возможно, но то было 40 лет назад. Тогда они может даже хорошим инструментом были. Но наслоения невыкидываемых легаси и потом наслоения мусорного кода для управления слоями мусорного легаси похоронили под собой возможную пользу. Ещё свой вклад внесло наркоманское m4 в основе - его никто не понимает и тупо копипастит у соседа, вместе с кучами ненужных действий.

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

Всмысле «сама отключить»? Это что за самодеятельность? Нет, «система сборки» должна спросить у юзера что ему нужно из фич, а потом уже на основе ответов выбрать зависимости. «Спросить что нужно» можно как раз через аргументы make. Если хочешь, можно интерактивный скрипт-конфигуратор для них сделать, такой есть в freebsd портах например - расставляешь галочки а потом по итогам генерится командная строка запуска сборки (кстати там никаких ни автотулзов ни тем более cmake не используется, всё через Makefile + спец утилита для рисования галочек - и работает намного быстрее перечисленной блоатвари).

Поведение «просто отключим то к чему нет либ» я видел у wine (во времена около версий 1.4, позже не интересовался) и оно весьма раздражало - приходилось ловить эти варнинги в логе чтоб вовремя понять каких либ не хватает, иначе придётся потом всё пересобирать.

Так вы ж сами предлагали, перед сборкой, всё ж скриптиком поискать что-нибудь, хотя бы хедера… А теперь снова компилятор? :)

Варианта два:

1) спрашиваем у gcc список путей к инклюдам и библиотекам, и ищем по ним сами

2) запускаем команду типа gcc dummy.c -lsomename и смотрим код возврата (да, похоже на автотулзы опять)

Ну вот народ нашёл какой-то muon-meson, который пистона не требует.

Замену meson на muon одобряю. Но на мой взгляд с этим всем с самого начала не надо было связываться.

Ещё свой вклад внесло наркоманское m4 в основе

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

Всмысле «сама отключить»? Это что за самодеятельность?

Как автор заложит, так она и сделает. Самодеятельности тут нет.

Нет, «система сборки» должна спросить у юзера что ему нужно из фич

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

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

Да нет, спасибо, я уж как-нить готовым воспользуюсь. :)

и оно весьма раздражало

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

Варианта два:

Да нет, не 2. :) Ещё - «использовать систему сборки» есть вариант. А вот писать скриптами свою - это как раз НЕ вариант.

Замену meson на muon одобряю.

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

Уйти с CMake на более конфигурируемые системы сборки, которые позволят им писать подобные велосипедики (раз уж у них сложная сборка), но уже удобно и на полноценном ЯП по типу Lua, JavaScript, Python вместо CMake-кастрата.

В идеале крестам нужно что-то наподобие Cargo, где кастомные скрипты для сборки крестопроектов можно писать на самих крестах, а не на уродливом процедурном высере CMake. То есть что-то вроде build.rs, только на С++. Этакий build.cpp. В принципе кресты позволяют задизайнить более-менее приличный EDSL с Fluent API, чтобы на нем писать эти самые build.cpp. Возможно даже не сильно хуже того же питона.

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

Я вот даже навскидку вообще не смогу назвать БОЛЕЕ худший DSL, чем тот что реализован в CMake.

Как насчет qmake?

qmake всё. Qt сваливает на cmake. А больше qmake никому не нужен.

В принципе кресты позволяют задизайнить более-менее приличный EDSL с Fluent API, чтобы на нем писать эти самые build.cpp. Возможно даже не сильно хуже того же питона.

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

Всё так. То что CMake получился всратым и архитектурно неполноценным это понятно. Но лично мне непонятно другое – почему сишники и крестовики, которые в своей массе неглупые в общем-то люди, завязались на него и теперь ходят по интернетам и собирают FindModule’и с костыликами себе в папочки cmake как будто так надо и это то, к чему они так стремились. Кроме разработки основого кода писать ещё и копировать убогие костыли для CMake.

Ей-богу, лучше бы в стандарт C++ пропихнули сборочную систему и пилили её.

Как насчет qmake?

Да там всё адекватно было вполне. Этакий кросс-платформенный Makefile с адекватными ?=, += и прочим. Единственный mind fuck который я помню из QMake и с которым часто сталкивались люди это ЗАХАРДКОЖЕННЫЙ 1tbs стиль в местном DSL:

static 
{
   something
}

# ^ Parse Error ('static') Unterminated conditional

static {
   something
}

# ^ Ok

Это действительно шляпа и так нельзя делать, но QMake всегда было приятнее использовать чем CMake.

Qbs же ещё есть, но я его не тыкал, может годно.

Есть. Годно если ты любишь декларативщину. И не простую, а расширяемую.

Оно точно адекватнее CMake и QMake. И даже несмотря на то, что Qt повёлся на моду и ушёл в сторону CMake, выкидывать Qbs они ещё не спешат, потому что внезапно он немного выстрелил в Embedded Development. Тут вот даже на LOR’е есть тройка Embedded-разрабов которые используют Qbs в своих проектах.

То есть что-то вроде build.rs, только на С++. Этакий build.cpp. В принципе кресты позволяют задизайнить более-менее приличный EDSL с Fluent API, чтобы на нем писать эти самые build.cpp. Возможно даже не сильно хуже того же питона.

Есть такой: https://github.com/coder137/build_in_cpp

Согласен, qmake - божественен. К сожалению, приходится постепенно ползти на cmake…

Этакий build.cpp.

И тут я такой врываюсь весь в белом на белом коне.

UPD. Поскольку пример по ссылке – убожество без хелперов, вот так выглядит cakefile.cpp одной из моих библиотечек. Make-правила генерятся хелперами, причём одновременно и для debug, и для release (соответственно, компиляция и тестирование debug и release версий выполняется параллельно); make-like двигло вызывается подпрограммой. На голом make вы запаритесь писать произвольную логику, про всякую сабжевую дрянь вообще молчу.

Так что идеологически я полностью согласен с firkax: make как концепция – идеален. А технически, всё что поверх него клепают, включая сабж, – собственно концепции make-правил ортогонально, всё это лишь попытки упростить генерацию правил. Но почему-то идут по пути кастомных ДЕКЛАРАТИВНЫХ языков. С соответствующим неизменным результатом.

…наркоманское m4… …его никто не понимает…

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

Но лично мне непонятно другое – почему сишники и крестовики, которые в своей массе неглупые в общем-то люди, завязались на него и теперь ходят по интернетам и собирают FindModule’и с костыликами себе в папочки cmake

Из-за отсутствия в С++ стандартного пакетного менеджера сишники и крестовики часто создают папочку аля 3rdparty и накачивают туда сторонних библиотек из интернетов. Возможно и папочку cmake они создают по той же самой привычке, накачивают туда FindXXX.cmake костылей и не видят в этом ничего зазорного. Это_норма.жпг

Но это все равно не объясняет, почему большинство завязалось на CMake. Допустим многие побежали на него после того, как популярные IDE (CLion, Visual Studio, Qt Creator) добавили поддержку CMake. Типа раз большие дяди его юзают, то и нам надо срочно на него переходить. Карго-культ, все дела. Но поддержка CMake в IDE это уже следствие возросшей популярности. А вот в чем изначальная причина популярности - загадка. Только потому, что этот набор костылей мог худо-бедно генерировать рабочие проекты под всякие визуальные студии, XCode, а также разные сорта мейкфайлов?

А вот в чем изначальная причина популярности - загадка

Википедия пишет:

Разработка CMake началась в 1999 году в ответ на потребность в кроссплатформенной системе сборки для ITK, финансируемой национальной библиотекой медицины США части Visible Human Project. Задача по разработке была возложена на небольшую компанию Kitware. На него повлияла более ранняя система pcmaker, созданная Кеном Мартином (Ken Martin) и другими разработчиками для поддержки инструментария визуализации (VTK).

В то время обычным считалось использование конфигурационных сценариев и make-файлов для сборки программных проектов на Unix-платформах и файлов проектов Visual Studio в среде Windows. Такой подход к разработке вызывал огромное неудобство, например, добавление одного файла исходного кода в проект приводило к большим трудностям, так как для каждой платформы это приходилось делать по отдельности и совершенно разными методами. Очевидно, что разработчики нуждались в единой унифицированной системе сборки, не отнимающей лишнее время.

https://github.com/coder137/build_in_cpp

Спасибо! Действительно очень похоже на Cargo-like скрипты сборки, о которых я говорил. Глянул примеры - смотрится неплохо, использует std::filesystem::path вместо примитивных строк, Fluent API и т.д. Жалко, что проект заглох и не вышел из стадии проверки концепта.

cmake шлак. Особенно нравятся его доки - огромные портянки ни о чем. Какие-то 100500 опций, старый стиль, новый стиль, туда не ходи… . Да нах так заморачиваться. Да даже архаичная связка autoconf+make - сильно симпатичней.

Были надежды на xmake, связанные с тем, что он умеет дергать компиль напрямую и может не решать странную задачу - генерить проектики для всяких вазелиновых студий. Но может не разобрался, но слишком всё «автоматизированно», не нашёлся проект в сестеме, значит подтянется из сети, как отключить - не понял.

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