CMake 3.28

Так не для моей.

Пишу я в CMakelists:

#discover poco libraries
find_package (Poco COMPONENTS NetSSL Foundation REQUIRED)
set (Poco_USE_STATIC_LIBS OFF)

Спрашивается, откуда cmake узнает про Poco? А вот откуда. Добрые люди в пакет libpoco-dev включили вот такое:

dpkg -L libpoco-dev
.....
/usr/lib/x86_64-linux-gnu/cmake
/usr/lib/x86_64-linux-gnu/cmake/Poco
/usr/lib/x86_64-linux-gnu/cmake/Poco/FindPCRE.cmake
/usr/lib/x86_64-linux-gnu/cmake/Poco/PocoActiveRecordConfig.cmake
/usr/lib/x86_64-linux-gnu/cmake/Poco/PocoActiveRecordConfigVersion.cmake
/usr/lib/x86_64-linux-gnu/cmake/Poco/PocoActiveRecordTargets-none.cmake
/usr/lib/x86_64-linux-gnu/cmake/Poco/PocoActiveRecordTargets.cmake
/usr/lib/x86_64-linux-gnu/cmake/Poco/PocoConfig.cmake
......

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

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

Нет конечно! Но вы не отвечаете на простой вопрос: почему ваша libpoco предоставляет ЭТО, а не .pc файлы для пкгконфига?

А вот это не ко мне вопрос. Она сама собирается cmake'om. Сам удивляюсь (и не только я), но в поставке нет никаких *.pc.

А вот это не ко мне вопрос. Она сама собирается cmake’om. Сам удивляюсь (и не только я), но в поставке нет никаких *.pc.

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

А если модулей для пкгконфа не предоставили? Вот как Poco, например? Вот и приходится собирать или руками (читай — мейкфалом), или тем, для чего есть конфиги.

А если модулей для пкгконфа не предоставили? Вот как Poco

Мезон поддерживает поиск зависимостей как через пкгконф, так и через симейковские скрипты. Однако генерить сам он умеет только первые. И уж точно не предлагает никому ещё какой-то свой вариант поставок.

А если модулей для пкгконфа не предоставили?

А если модулей для CMake не предоставили? Вот как [огромный список либ] например?

Почему разработчикам теперь нужно лазить по чужим репозиториям с огромным мешком и собирать коряво работающие FindModules? Или писать их самому?

1. https://github.com/ihhub/fheroes2/blob/master/cmake/FindSDL2_mixer.cmake
2. https://github.com/ksterker/adonthell/blob/master/config/FindSDL2_mixer.cmake
3. https://github.com/linkdd/sdl-game-engine/blob/master/cmake/FindSDL2_mixer.cmake
4. https://github.com/neoaggelos/tap/blob/master/cmake/FindSDL2_mixer.cmake
5. https://github.com/metatrevor/mchezo-engine/blob/master/cmake/FindSDL2_mixer.cmake
6. https://bitbucket.org/andreyu/simple-viewer-gl/src/master/cmake/

Какой из этих пяти абсолютно разных говномодулей адекватный и корректный?

И это ты действительно называешь «действительно более удобная замена автотулзам»?

И это ты действительно называешь «действительно более удобная замена автотулзам»?

Вообще, я бы опрос добавил. По идее, мезон должен победить. Но, учитывая то, насколько он новый (в релизную 1.0 фазу вошёл год назад), может статься так, что симейковские старпё^^стартаперы нас и задавят. :)

По идее, мезон должен победить

Не должен, мы ведь в Clown World живём где worse is better.

Разработчики разного окололинуксового по типу X.Org, Wayland, GLib, GTK+, QEMU, systemd и пр. конечно поковырялись с CMake и ушли на Meson, но это всего лишь капля в море тухлых CMake-портянок и заплесневелой autotools-лапши.

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

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

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

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

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

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

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

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

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

Ну, симейковские старпё^^стартаперы... :)

Для меня и cmake-то новость. :)

А если модулей для CMake не предоставили?

писать их самому?

В чем проблема написать самому? Ну кроме твоих кривых рук?

В чем проблема написать самому?

А почему я должен выполнять работу за инфантильных лентяев из Kitware, которые сначала обязались поставлять с дистрибутивом CMake эти FindModules для популярных библиотек, а потом нарушили собственные обещания скинув написание этого дерьма на рядовых программистов?

В чем проблема

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

https://github.com/search?q=FindSDL2_mixer.cmake+language%3ACMake&type=code&l=CMake

~300 мать его реализации FindSDL2_mixer.cmake и каждая на свой лад! Конечно, полоумные фанатики CMake вроде тебя не видят здесь фундаментальных изъянов в архитектуре CMake поделия и продолжают писать такие же велосипеды или ходить с огромным мешком по GitHub’у и собирать их в отдельную cmake папочку.

А почему я должен выполнять работу

Ох, только не плачь, иди в грузчики в пятерочки.

Ох, только не плачь, иди в грузчики в пятерочки.

Ты уже создал «папочку» cmake в своём проекте для складывания кривоработающих Find-модулей и прочих костыликов с GitHub’а, виндузятник?

Ты уже создал «папочку» cmake в своём проекте для складывания кривоработающих Find-модулей

Я свои делаю, я прусь с этого.

полоумные фанатики CMake … продолжают писать такие же велосипеды

Ты так и не ответил, что делать в твоем любимом meson если нет pkg-config. Сразу отметаем cmake-велосипеды как ненужное говно, а потом что? Делаем более другой велосипед, написав портянку из питоньей дристни?

А нахера лазать по репам? Проблема решается обычно или «изкаропки», или по мере поступления. Поставщики популярных библиотек пишут или pkg-config, или макросы для cmake. Когда-то писали макросы для автоконфа. Вынимать что-то из внешнего гита в процессе сборки — дурной тон и вообще опасно. Кто сказал, что TOT работает и автор репы нужную ветку не убил?

Вот мы уже выяснили, что если в поставке libPoco модуля для pkg-config'a, то мезон будет вытаскивать инфу из симейка. Мезон «из глубин своего духа» инфу не вытащит, он про Poco в душе не разумеет. Откуда ни возьмись ничего ниоткуда не возьмется.

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

По синтаксису и объему сборочного скрипта, да, cmake удобнее autotools.

Поставщики популярных библиотек пишут или pkg-config, или макросы для cmake.

Да не выдавайте вы желаемое за действительное. Ну кто-то когда-то напилил для 1й конкретной либы симейк-скрипты, а пкгконф - забыл. И у вас это трансформировалось в «Поставщики популярных библиотек пишут… или макросы для симейк». Да не пишут.

то мезон будет вытаскивать инфу из симейка.

Сам он ничего делать не будет, но, при объявлении зависимости, вы можете указать метод поиска. В данном случае, cmake. А по умолчанию - пкгконфиг.

Мезон «из глубин своего духа» инфу не вытащит, он про Poco в душе не разумеет.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В принципе кресты позволяют задизайнить более-менее приличный 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 в своих проектах.

Но лично мне непонятно другое – почему сишники и крестовики, которые в своей массе неглупые в общем-то люди, завязались на него и теперь ходят по интернетам и собирают 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. Такой подход к разработке вызывал огромное неудобство, например, добавление одного файла исходного кода в проект приводило к большим трудностям, так как для каждой платформы это приходилось делать по отдельности и совершенно разными методами. Очевидно, что разработчики нуждались в единой унифицированной системе сборки, не отнимающей лишнее время.

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

Да, все так и было. Опишу личный опыт. Помню, под вантуз обычно создавали проект Visual Studio, под мак делали проект XCode, под онтопик заводили мейкфайл и писали код в каком-нибудь Code::Blocks. Позже стали использовать Qt Creator с qmake. Основным эталонным проектом обычно считался студийный и вся разработка шла в первую очередь там. Затем проекты под другие платформы периодически синхронизировали со студийным. Чаще всего синхронизация сводилась к простому добавлению новых С++ файлов в проект.

ИЧСХ, никаких «огромных неудобств» это почему-то не создавало. Буквально повозюкал мышью в условном XCode проекте пять минут, накидал туда новых файлов драгдропом, потыкал гуевые настройки и вуаля - вот и тебе и поддержка нескольких проектов под разные платформы . Когда я предлагал попробовать малоизвестный тогда CMake, на меня недоуменно смотрели как на идиота и крутили пальцем у виска. Ибо зачем пилить какие-то мутные скрипты на нетипизированном уродце CMake, когда можно просто в гуйне натыкать нужные настройки под каждую платформу. На CMake со скрипом стали переходить только после того, как студия, а позже CLion, добавили нативную поддержку CMake. И то, долго плевались и скучали по гуевым настройкам.

Поэтому меня и удивляет, почему крестовики, в массе своей шарящие за статическую типизацию и хорошие практики разработки, начали мигрировать на CMake и считать его чем-то правильным и нормальным. Воистину worse is better.

Поэтому меня и удивляет, почему крестовики, в массе своей шарящие за статическую типизацию и хорошие практики разработки, начали мигрировать на CMake и считать его чем-то правильным и нормальным. Воистину worse is better.

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

ИЧСХ, никаких «огромных неудобств» это почему-то не создавало. Буквально повозюкал мышью в условном XCode проекте пять минут, накидал туда новых файлов драгдропом, потыкал гуевые настройки и вуаля - вот и тебе и поддержка нескольких проектов под разные платформы

Ну вот мой текущий проект на cmake под lin/win/mac. Вот допустим я запилил новый модуль/класс и т.п. Добавляю исходники. Рабочий ноут на винде и есть мак мини, линукс в виртуалке. По твоему сценарию мне нужно закомититься на винде, запушиться, включить виртуалку линукс, запулиться, внести изменения, звпушиться и еще повторить на маке. Супер!!! А сейчас я вношу изменения в CMakeLists.txt, запушиваю. Запускаю сборку на jenkins на трех системах, смотрю ок или нет и далее по таска процессам идет. Конечно же твой сценарий намного удобнее :-)

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

Все верно. По личному опыту в десктопной разработке этот подход ВНЕЗАПНО неплохо работал. Основным и эталонным проектом обычно считался студийный. Именно он пилился и тестировался в первую очередь. Где-то ближе к концу очередного спринта, обычно с периодичностью в две-три недели, Mac и Linux версии синхронизировались с вантузным. Чаще всего этим занимался отдельный разработчик, так что виндузне не требовалось заводить виртуалки и разбираться в никсах. Обычно вся синхронизация сводилась к добавлению недостающих файлов в Mac/Linux проекты, реже к мелким правкам компиляции, натыкиванию #ifdef и дописыванию платформо-зависимых частей.

По личному опыту в десктопной разработке этот подход ВНЕЗАПНО неплохо работал

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

Основным и эталонным проектом обычно считался студийный. Именно он пилился и тестировался в первую очередь.

Ну а вот у нас win/mac - основные таргет системы, Linux - уже по остаточному. И собираются/тестируются постоянно. Если ты предлагаешь при добавлении нового файла исходников каждый раз в трех местах править - спасибо, я лучше как нибудь на cmake в одном месте сделаю.

Где-то ближе к концу очередного спринта, обычно с периодичностью в две-три недели, Mac и Linux версии синхронизировались с вантузным. Чаще всего этим занимался отдельный разработчик, так что виндузне не требовалось заводить виртуалки и разбираться в никсах. Обычно вся синхронизация сводилась к добавлению недостающих файлов в Mac/Linux проекты, реже к мелким правкам компиляции, натыкиванию #ifdef и дописыванию платформо-зависимых частей.

Вместо того, чтобы один раз во время разработки таски весь код, который к ней относиться, проверить на собираемость и проверить тестировщиком на всех системах, делаем это только для винды. Потом через три недели отвлекаем разработчика от текущих дел и заставляем заниматься этой таской, и другими по той же причине, которые не факт что он делал и вносим дополнительные изменения в исходники. Ой красота какая. А доп тестирование делаем? А исходная таска уже вмержена? У вас, я посмотрю, все круто поставлено. Хотя просто у вас mac/lin не в приоритете, или даже в принципе пофиг на эти системы.

Где-то ближе к концу очередного спринта, обычно с периодичностью в две-три недели, Mac и Linux версии синхронизировались с вантузным.

А про CI/CD слыхали?

А про CI/CD слыхали?

Слыхали и использовали. И тесты гоняли, и ночнушки собирали. Только делалось это в первую очередь для вантузного проекта, а потом уже для остальных Tier II платформ. Что было банально продиктовано бизнес потребностями и продажами под каждую платформу. ИЧСХ, это даже неплохо работало, потому что за 100% покрытием никто не гнался и юнит тестами покрывались в основном всякие расчетные алгоритмы, геометрические ядра CAD и прочая суровая логика. А все это обычно никак не зависит от ОС/компилятора, поэтому необходимости постоянно гонять CI/CD пайплайн на всех возможных платформах не было.

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

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

А представь когда различных ИДЕ/редакторов кода куча, куча операционных систем, дистрибутивов, компиляторов и всё это должно поддерживаться и тестироваться непрерывно, а не от случая к случаю.

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

Бинго! Это может порвать шаблоны фанатов CMake, но бывают проекты, где кроссплатформенная разработка - есть, CI/CD пайплайн - есть, а вот самого CMake - нет.

А представь когда различных ИДЕ/редакторов кода куча, куча операционных систем, дистрибутивов, компиляторов и всё это должно поддерживаться и тестироваться непрерывно, а не от случая к случаю.

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

Я говорю, что есть множество кейсов, где без него прекрасно можно обойтись.

Ну это другое, с этим вроде бы никто не спорит. Без с++ тоже можно вполне обойтись, есть множество кейсов.

Но это все равно не объясняет, почему большинство завязалось на CMake.

Меня больше интересует, почему не стал популярным tup? Уж Lua (в случае такой необходимости) всяко поприятней скриптов CMake.

tup

О, любопытная штука

Да. Из более-менее больших проектов, tup используется в KolibriOS.

Но это все равно не объясняет, почему большинство завязалось на CMake.

Очевидно потому что альтернативы тогда не было. Я писал примерно тогда 2001 сборку средненького проекта на чистом make. Проект поддерживал сборку на виндосе и линуксе, кросскомпиляцию на несколько платформ, я даже слепил генерацию проектных файлов для вижуал студио и кодекомпозера от техас инструментс (и даже частично импорт из них обратно). И это всё работало, конечно, но… Это было больше похоже на магию для других разработчиков в этом же проекте. Слишком сложно для понимания. CMake облегчает и упрощает многие стандартные задачи своими многочисленными готовыми встроенными командами.

Потом какое-то время работал с tmake и qmake, но те были слишком привязаны к Qt.

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

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

Кстати почему никто не вспомнил про базель? Очень даже хорошие идеи заложены. Но не взлетит конечно.

Кстати почему никто не вспомнил про базель? Очень даже хорошие идеи заложены. Но не взлетит конечно.

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

Он давно уже взлетел

Сыроват, на мой взгляд, документация куцая, для массового применения непригоден.

Всё ещё жив за счёт гугла, судя по всему. В свободном плавании - не жилец.

Всё ещё жив за счёт гугла, судя по всему. В свободном плавании

• не жилец.

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

Повторяю: он в корпоративном сегменте жилее всех жильцов.

Ну так я же и не спорю, разве гугл не корпоративный сегмент? Я так и говорю, что за счёт гугла жив. И будет жить пока гугл его двигает. Но может они его и доделают когда-нибудь. Основа-то хорошая. Допилить думаю можно.

Ну так я же и не спорю, разве гугл не корпоративный сегмент? Я так и говорю, что за счёт гугла жив.

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

Основа-то хорошая. Допилить думаю можно.

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

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

Потому что его в гугле разработали. В нём и используется.

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

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

Нетфликс это который сериалы клепает? А как он его допилит и зачем? И вообще, нафига нетфликсу система сборки?

Не, я имею в виду авторов базеля, которые в гугле сидят. Если допилят, то шансы есть. Не допилят, так он там и будет дальше вариться, по корпорациям… А жаль, в принципе задумка-то неплохая. Мог бы выйти в люди.

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

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

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

Ему фиолетово на ваше мнение. К тому же, вы, похоже, просто потролить решили.

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

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

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

Ещё как вариант, может быть, кто-то форкнет и доведёт до ума.

Ему фиолетово на ваше мнение.

Да я как бы и не навязываюсь.

Кстати почему никто не вспомнил про базель? Очень даже хорошие идеи заложены. Но не взлетит конечно.

Пробовал. Он оставил у меня ощущение очень приятного по синтаксису и вместе с тем сырого продукта.

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

Пробовал. Он оставил у меня ощущение очень приятного по синтаксису и вместе с тем сырого продукта.

Точно! У меня тоже. Такое впечатление что бросили не доделав.

Я использую cmake где-то с 2007 года. Да, он крив, но геморроя с ним меньше чем с альтернативами. Мне еще раньше нравилась возможность генерации vcproj, но сто лет уже не пользовался этим функционалом. FindXXX.cmake почти все кривые, я по возможности вызываю pkg-config из cmake.

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

Ты говоришь про карго культ не понимая всех причин.

Вот есть кроссплатф-ый проект на 3 платформы win/mac/linux. Как мне его собирать? Держать три проекта под msvc/xcode/make ? - очень удобно. Или как? Как мне его собрать относительно унифицировано в консоли, чтобы сборку можно было запускать из скриптов.

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

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

Вот есть кроссплатф-ый проект на 3 платформы win/mac/linux. Как мне его собирать? Держать три проекта под msvc/xcode/make ? - очень удобно.

ВНЕЗАПНО да, держать три проекта под Windows/Mac/Linux может быть удобнее, по крайней мере для проприетарной разработки. Уже писал про это в другом посте. В двух словах - сложность поддержки трех проектов сильно преувеличена. А сложность зазубривания уродского велосипедного языка CMake и ковыряния в груде CMake костылей наоборот сильно преуменьшена. Все равно практически в любом CMake-базед проекте сложнее хелловорлда приходится постоянно городить портянки if(WIN32) ... elseif(APPLE) ... else() ... endif() и забивать туда платформенно-специфичный код. Что не сильно далеко ушло от поддержки трех разных файлов проектов. В CMake хоть варнинги можно кроссплатформенно включить или до сих пор надо пердолить if/else/endif под каждый компилятор?

Как мне его собрать относительно унифицировано в консоли, чтобы сборку можно было запускать из скриптов.

msbuild для проектов визуальной студии, xcodebuild для XCode, ну и make само собой. Ну да, не унифицированно, а через if/else, но тебя же набивка аналогичных if/else в CMake скриптах тоже не смущает.

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

Взамен мы полностью лишаемся удобной настройки проекта из гуйни Visual Studio и XCode. Все что раньше делалось в несколько кликов мышью, теперь требует написания портянок скриптушни на уродском нетипизированном DSL с отвратительной документацией. Стоит ли оно того? Ну не знаю, решает каждый сам для себя.

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

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

ВНЕЗАПНО да, держать три проекта под Windows/Mac/Linux может быть удобнее, по крайней мере для проприетарной разработки. Уже писал про это в другом посте. В двух словах - сложность поддержки трех проектов сильно преувеличена

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

В CMake хоть варнинги можно кроссплатформенно включить или до сих пор надо пердолить if/else/endif под каждый компилятор

Нужно (хотя есть CMAKE_COMPILE_WARNING_AS_ERROR, но я эту не использовал, поэтому не могу сказать, удобно ли это.), а в случае трех проектов не нужно?

msbuild для проектов визуальной студии, xcodebuild для XCode, ну и make само собой. Ну да, не унифицированно, а через if/else, но тебя же набивка аналогичных if/else в CMake скриптах тоже не смущает.

Набивка каких аналогичных if/else? Запуск будет ‘cmake –build …’

Взамен мы полностью лишаемся удобной настройки проекта из гуйни Visual Studio и XCode

Это субъективщина. Мне визуальные настройки неудобны.

Все что раньше делалось в несколько кликов мышью, теперь требует написания портянок скриптушни на уродском нетипизированном DSL

А по мне визуальная настройка в Xcode/VS - это уродское кликание по херовой горе окошек, что потом глаза вянут.

с отвратительной документацией

Не подтверждаю. Вполне норм доки. И достаточно подробные.

А теперь продолжим. Если я работаю в Qt Creator / CLion / Vim, что мне делать? Переучиваться на XCode / VS ? С хера ли?

А если я хочу попробовать собирать на Ninja ? - переписывать все на Ninja? Например мой текущий проект собирается на VS 12-13 мин, а на Ninja 10 мин. А если я хочу потом вернуться на VS то что снова переписывать?

А если я пишу опенсорс библиотеку (каких множество) и использую другие кроссплатформенные библиотеки, то то мой код будет тоже кроссплатформенный и код моего CMakeLists.txt тоже, и использование моей библиотеки на трех ОС также будет сведен к одинаковым вызовам нескольких cmake комманд. А если делать три проекта, то сколько дублирования будет по итогу, не хочешь сказать?

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

А CMake сейчас по сути стал некоторой формой замены этого формата. Его создатели правильно уловили потребности разработчиков. И не было бы этой необходимости - не было бы cmake.

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

Сложность поддержки трех проектов, как я уже писал, сильно преувеличена адептами CMake. Файлы и ассеты перетаскиваются мышью в проект за пару секунд. Для многих намного удобнее сделать это два/три раза в IDE, чем вбивать списки файлов руками в CMake скрипте. Для выполнения специальных действий в гуевых настройках есть всякие Pre/Post Build Events. Опять же, не составляет особых проблем забить туда нужные команды на поверщели или баше. Тем паче, что многие ассеты типа иконок и ресурсов изначально платформозависимы, лежат по разным путям, имеют разные форматы, и даже в CMake один хрен приходится использовать if/else/endif.

а в случае трех проектов не нужно?

В случае трех проектов ты просто открываешь настройки проекта в IDE и тыкаешь мышью в человекочитабельные и понятные опции аля Warning Level или Pedantic Warnings. А не ковыряешься в if/else/endif скриптушне и не выискиваешь флаги компилятора вроде /W3 и -Wall.

Набивка каких аналогичных if/else? Запуск будет ‘cmake –build …’

Ну а в случае трех проектов запуск будет через условный if (вантуз) msbuild ... elseif (мак) xcodebuild ... else make ... endif. Сложно? Да как-то не особо. В CMake скриптах ты же как-то привык набивать if/else/endif и не считаешь это чем-то зазорным. Вот и любителям трех разных проектов сборка разными командами через if/else/endif тоже норм.

Это субъективщина. Мне визуальные настройки неудобны.

Да, это субъективщина. Поэтому я не призываю всех срочно бросать CMake и перебегать на проекты IDE. Просто описываю личный опыт. Многим после удобств проприетарных IDE симейк скрипты кажутся регрессом и деградацией. Лично наблюдал обратную миграцию с CMake на Visual Studio и Xcode в одном из проектов. CMake там остался чисто для сборки под онтопик вместо мейкфайлов.

Не подтверждаю. Вполне норм доки. И достаточно подробные.

Норм доки - это например Qt или MSDN. А CMake - это все что угодно, только не нормальные доки. Хуже этих доков может быть разве что их отсутствие.

Если я работаю в Qt Creator / CLion / Vim, что мне делать? Переучиваться на XCode / VS ? С хера ли? А если я хочу попробовать собирать на Ninja ? - переписывать все на Ninja?

В проприетарной разработке ты как правило будешь писать на том, на чем тебе скажут. Если брать десктопную разработку, то почти наверняка это будут Visual Studio и Xcode. Популярность CLion и Qt Creator можно приблизительно оценить по ежегодному опросу StackOverflow. И хаотичные метания с MSVS на Ninja и обратно скорее всего не поприветствуют. «Миша, у тебя скучное лицо, тебе никто денег не даст» (c).

В проприетарной разработке вообще очень часто сборка намертво захардкожена. На каждой платформе используется ровно один компилятор. Проект собирается строго с фиксированными конфигурациями. Произвольная настройка через пользовательские опции (команда option в CMake) отсутствует. Зависимости кладутся в папочку 3rdparty и пути к ним хардкодятся в проекте, без всякого там поиска системных библиотек. Никто не будет тратить деньги и время разработчиков/тестировщиков на супер-пупер конфигурируемую сборку, позволяющую на лету менять компиляторы и библиотеки. И вот в таких условиях гибкость и расширяемость CMake оказывается по большей части бесполезной. Возникает вопрос - а не проще ли вместо CMake тупо использовать раздельные проекты Visual Studio и Xcode, идеально заточенные именно под проприетарную разработку?

А если я пишу опенсорс библиотеку (каких множество) и использую другие кроссплатформенные библиотеки

Воот. Опенсорсная разработка - это именно та ниша, где нужны скрипты сборки вместо проектов IDE. Ибо разработчики должны предоставить возможность гибко конфигурировать сборку под нужды пользователей, чего фиксированные форматы IDE проектов не позволяют. Да и завязка на проприетарные IDE в опенсорсе не комильфо. Только вот всратый CMake - это пожалуй один из худших вариантов для написания подобных скриптов. Хуже разве что автотулзы, хотя CMake в общем-то недалеко от них ушел. Как я уже раньше писал, намного лучше было бы писать скрипты сборки на самих крестах.

Сложность поддержки трех проектов, как я уже писал, сильно преувеличена адептами CMake

Так можно что угодно оправдать: сложность сопровождения дублированного в трех местах кода сильно преувеличена адептами вынесения общего кода в отдельные функции.

Для многих намного удобнее сделать это два/три раза в IDE, чем вбивать списки файлов руками в CMake скрипте

Печатаешь руками, а кликаешь/перетаскиваешь чем? Ногами?

Для выполнения специальных действий в гуевых настройках есть всякие Pre/Post Build Events. Опять же, не составляет особых проблем забить туда нужные команды на поверщели или баше

Мда, в винде bat/ps пишешь, в linux/mac тоже самое повторяешь на bash. Лепота.

Тем паче, что многие ассеты типа иконок и ресурсов изначально платформозависимы

А одинаковые ассеты указываем в трех местах.

В CMake скриптах ты же как-то привык набивать if/else/endif

Во первых только платформа зависимые участки, а это не много. Во вторых это производится единообразно. В VS гуях же нужно пять раз кликнуть, раскрыть, промоать, открыть, скопировать, закрыть, нажать ok, открыть в другом месте, поставить галочку и т.п. У меня от этого приступы раздражения случаются.

Норм доки - это например Qt или MSDN. А CMake - это все что угодно, только не нормальные доки. Хуже этих доков может быть разве что их отсутствие.

Вполне удобные и подробные. Давай так: что ты в них не нашел?

В проприетарной разработке ты как правило будешь писать на том, на чем тебе скажут

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

Популярность CLion и Qt Creator можно приблизительно оценить по ежегодному опросу StackOverflow

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

И хаотичные метания с MSVS на Ninja и обратно скорее всего не поприветствуют. «Миша, у тебя скучное лицо, тебе никто денег не даст» (c).

Это вообще сравнение соленого с красным. MSVC - компилятор, Ninja - система сборки, типа make. Если она можеть дать +20% к скорости сборки - это отличная возможность сделать билд сервер чуть более быстрым. А если все гвоздями сделано на VS, то хер с два.

В проприетарной разработке вообще очень часто сборка намертво захардкожена

Ну и. Это не значит, что это хорошо. Часто так происходит, потому что писать начали давно, как умели и теперь тянут кучу костылей и либ бородатых версий. В одной такой конторе мне на голубом глазу объясняли сборку на VS: первый раз сборка скорее всего завершится ошибкой, потому что там что… а со второго раза должно все собраться.

Зависимости кладутся в папочку 3rdparty и пути к ним хардкодятся в проекте, без всякого там поиска системных библиотек. Никто не будет тратить деньги и время разработчиков/тестировщиков на супер-пупер конфигурируемую сборку, позволяющую на лету менять компиляторы и библиотеки. И вот в таких условиях гибкость и расширяемость CMake оказывается по большей части бесполезной. Возникает вопрос - а не проще ли вместо CMake тупо использовать раздельные проекты Visual Studio и Xcode, идеально заточенные именно под проприетарную разработку?

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

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

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

Вполне удобные и подробные. Давай так: что ты в них не нашел?

1. Нет примеров использования каждой опции в каждой команде. В нормальных доках многие функции и параметры иллюстрируются кодом, наглядно объясняющим как юзать эти вещи, для чего они нужны и в каких сценариях их использовать. В доках CMake ничего этого нет. Обычно там крайне скудное и сухое cryptic описание без всяких примеров использования. Пользоваться этим можно, только если ты годами дрочил на CMake, заранее знаешь что тебе нужно найти и используешь доки чисто в качестве справочника. А вот для изучения CMake они полностью бесполезны. Среднестатистические крестовики обычно открывают доки CMake, блюют дальше чем видят, закрывают, идут копипастить примеры из SO и таскать себе FindXXX.cmake скрипты из интернетов.
2. Нет best practices, которые показывают какие команды и опции надо юзать в современных проектах, а какие устарели и не рекомендуются. Де-факто есть два диалекта CMake: легаси и так называемый Modern CMake. Но доки ничего не говорят про эти диалекты. Там просто беспорядочно наблеваны все возможные команды и опции. Типа возитесь с ними сами как хотите.

Я уж молчу о том, что ублюдочный велосипедный DSL нарушает все мыслимые и немыслимые дизайны API. Есть например правило «магическое число семь», гласящее о том, что человек может одновременно держать в голове максимум семь объектов. Некоторые говорят, что на самом деле их еще меньше - четыре. Поэтому дизайнеры API обычно стараются делать не более 4 параметров в каждом методе. Например как в Qt.

Но бездари из Kitware про хорошие практики видимо ничего не слышали. В итоге мы имеем раздутые монструозные команды с десятками параметров и кучей альтернативных режимов работы. Причем в каждом релизе CMake постоянно добавляются все новые и новые команды и параметры, то бишь на уже существующие слои дерьма накидываются с лопаты новые слои дерьма. Ковыряться в этой параше у многих нет никакого желания. Проще бездумно скопипастить решение из SO или спросить у Чата Гопоты.

Как я уже написал, в своей нише универсального средства/формата описания проекта и его сборки ничего лучше cmake не придумали.

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

В VS гуях же нужно пять раз кликнуть, раскрыть, промоать, открыть, скопировать, закрыть, нажать ok, открыть в другом месте, поставить галочку и т.п. У меня от этого приступы раздражения случаются.

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

Лучше бы гомитет стандартизации […] придумал бы стандартный пакетный менеджер

Шайка меджународных террористов может разве что объявить единственно верным NuGet :D

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

И все дистрибутивы Линукса дружно наложат на этот пакетный менеджер анафему потому что у каждого дистрибутива уже есть родной пакетный менеджер.

Нет примеров использования каждой опции в каждой команде

А в том же Qt они точно есть? Прямо таки на все аргументы?

Нет best practices, которые показывают какие команды и опции надо юзать в современных проектах, а какие устарели и не рекомендуются. Де-факто есть два диалекта CMake: легаси и так называемый Modern CMake. Но доки ничего не говорят про эти диалекты. Там просто беспорядочно наблеваны все возможные команды и опции. Типа возитесь с ними сами как хотите.

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

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

Так и Qt также же. И много с чем еще. Основы нужно в книгах статьях учить.

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

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

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

Вот про «портянки ссанины» мне не очень нравится. И что значит «куда сможешь дотянуться». У меня нет самоцели. Просто при создании нового проекта я возьму Qt Creator + CMake.

а есть множество кейсов, где удобнее проекты IDE

Есть сомнения

Просто при создании нового проекта я возьму Qt Creator + CMake.

А мог бы взять qmake, в течении жизненного цикла Qt5 и Qt6 она точно поддерживается (а может, и дальше). Перейти на плохо читаемые портянки никогда не поздно, вот слезть с них…

А мог бы взять qmake

и поиметь хорошо читаемую портянку

greaterThan(QT_MAJOR_VERSION, 4) {
win32 {
tr.commands = lrelease \
    $$_PRO_FILE_
}
unix {
macx {
tr.commands = lrelease \
    $$_PRO_FILE_
} else {
tr.commands = lrelease-qt5 \
    $$_PRO_FILE_
}
}
} else {
win32 {
tr.commands = lrelease \
    $$_PRO_FILE_
} else {
tr.commands = lrelease-qt4 \
    $$_PRO_FILE_
}
}

которая в linux падает на сборке с Qt5

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

А в том же Qt они точно есть? Прямо таки на все аргументы?

Ну давай сравним нормальные доки с доками курильщика, чо. Вот например QString:

https://doc.qt.io/qt-6/qstring.html

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

А вот например документация на find_package в CMake:

https://cmake.org/cmake/help/latest/command/find_package.html#full-signature

Как нормальному человеку читать этот хреново структурированный высер дегенератов из Kitware, написанный отборным канцеляритом? Как быстро понять, какой параметр за что отвечает без текстового поиска по странице? Где хоть один пример использования find_package в CMake коде?

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

Так и Qt также же. И много с чем еще. Основы нужно в книгах статьях учить.

Так-то оно так, только любой С++/Qt разраб тебе скажет, что культи после изучения основ в целом интуитивно понятны и код можно шлепать автодополнением, почти не читая документацию. А вот с CMake у многих так почему-то не получается. Приходится гуглить на каждый чих и лазить по интернет помойкам в поисках FindXXX.cmake скриптов.

Да, кстати, чо там у CMake с книгами и статьями? Вот по культям книжек полно, а CMake чем может похвастаться? Mastering CMake от самих Kitware не предлагать, с ними уже все давно понятно.

Вот например QString

Ага, молодец. Посмотри, как классы Qt 3D «подробно описаны».

https://cmake.org/cmake/help/latest/guide/using-dependencies/index.html

де хоть один пример использования find_package в CMake коде?

Хотя бы тут https://cmake.org/cmake/help/latest/guide/using-dependencies/index.html

С++/Qt разраб тебе скажет, что культи после изучения основ в целом интуитивно понятны и код можно шлепать автодополнением, почти не читая документацию

Вот я, как C++/Qt разраб, тебе говорю, что если ты будешь шлепать автодополнением почти не читая доки, то будешь получать на выходе только хелоуворлды.

А вот с CMake у многих так почему-то не получается. Приходится гуглить на каждый чих и лазить по интернет помойкам в поисках FindXXX.cmake скриптов

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

Да, кстати, чо там у CMake с книгами и статьями? Вот по культям книжек полно, а CMake чем может похвастаться? Mastering CMake от самих Kitware не предлагать, с ними уже все давно понятно.

Вот есть отличная книга Дубров Денис Владимирович Система построения проектов cmake. Не очень новая, но много пробелов закрывает. После нее уже достаточно доков.

Давай так, я признаю недостатки cmake (как минимум отсутствие типов), и доки Qt конечно лучше. Но Вместе с тем доки cmake вполне норм. Бывает гораздо хуже.

Ага, молодец. Посмотри, как классы Qt 3D «подробно описаны».

Документация на Qt 3D конечно кал, как и сам модуль. Но есть нюанс. QString (и модуль Qt Core вообще) использует любой C++/Qt разраб, а Qt 3D - почти никто. В репозиториях арча нашел только два приложения, использующих Qt 3D: meshroom и qgis. Так что плохие доки на Qt 3D вряд ли кого-нибудь сильно расстроят, а вот плохие доки на find_package - примерно всех.

У меня было бы сильно меньше претензий к докам CMake, если бы основные концепции и команды были подробно разжеваны не хуже, чем Qt Core. Ну а редко используемые команды остались бы как есть.

Вот есть отличная книга Дубров Денис Владимирович Система построения проектов cmake.

Ожидал, что будет корявый машинный перевод доков CMake, но на удивление все довольно неплохо для 2015 года. Жирный плюс за главу с примерами использования OpenCV, Boost, Qt.

Давай так, я признаю недостатки cmake (как минимум отсутствие типов), и доки Qt конечно лучше. Но Вместе с тем доки cmake вполне норм. Бывает гораздо хуже

Ну здесь полностью согласен, не поспоришь. Бывает вообще отсутствие документации :)

Да, кстати, чо там у CMake с книгами и статьями? Вот по культям книжек полно, а CMake чем может похвастаться? Mastering CMake от самих Kitware не предлагать, с ними уже все давно понятно.

Гугл спроси, там хоршие ответы

Вот первая же ссылка, например

Там как раз раскрыто, что плохо, что хорошо, лучшие практики и современный симейк и легаси.

Впрочем и вторая и третья ссылки вроде тоже ничего.

«На безрыбье и рак рыба».

Не понял, что тебе не нравится?

В треде не было постов о системах сборки, которые просты и удобны.

Один пост в треде (не мой) был о том, что должна быть разработана удобная система сборки, которая заменит все системы сборки (make, cmake, ...).

Такой tools вполне реально разработать.

Такой tools вполне реально разработать.

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

Такой tools вполне реально разработать.

как_множатся_стандарты.жпег

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

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

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

Такой tools вполне реально разработать.

Да, и обязательно с зависимостью от libclang, чтобы был интерпретатор C++ JIT. :)

Да, кстати, чо там у CMake с книгами и статьями?

https://github.com/onqtam/awesome-cmake

хреново структурированный высер дегенератов из Kitware

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

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

Но только вот этого

стандартную либу для написания сборочных скриптов на крестах

не надо.

Как не нужен и симейк «для крестов». Система сборки должна быть универсальной.

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

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

Вот если бы ты говорил о каком-то подмножестве с++ и интерпретаторе с++ встроенном в сборочную систему, тогда ладно.

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

Спорно. Идея-то хорошая, но на практике это особо не работает. Вокруг каждого языка образуется свое сообщество, которое пилит тулинг именно на этом языке. Так проще писать и контрибутить в этот тулинг. Если ты посмотришь на какой-нибудь JavaScript/TypeScript, то основные инструменты типа npm, ESLint, Prettier, WebPack, Vite и т.д. написаны на том же самом JavaScript/TypeScript. Равно как и у крестовиков стандартом де-факто стал именно CMake на С++, а не скажем Gradle или даже Meson, хотя последние отлично могут собирать крестопроекты. Поэтому если ты напишешь супер-пупер универсальную систему сборки на крестах, то никто кроме крестовиков ей пользоваться скорее всего не будет.

Вот если бы ты говорил о каком-то подмножестве с++ и интерпретаторе с++ встроенном в сборочную систему, тогда ладно.

Есть такой интерпретатор! Cling называется. Самый настоящий интерпретатор с REPL, который может запускать C++ скрипты без функции main. На днях как раз релиз 1.0 вышел.

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

Спорно. Идея-то хорошая, но на практике это особо не работает.

make же в своё время взлетел и стал стандартом отрасли на многие десятилетия и до сих пор используется.

инструменты типа npm, ESLint, Prettier, WebPack, Vite и т.д. написаны на том же самом JavaScript/TypeScript

Я конечно в жабаскрипте не разбираюьсь, но при чём тут система сборки? Эти всё инструменты не для сборки. Ну и зачем приводить в пример скриптовый язык. Понятно что система сборки нужна в первую очередь для языков компилируемых/транслируемых. Фортран, Паскаль, Раст и т.п.

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

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

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

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

Глядя на С++ код, очень редко встречаешь что-то читабельное. А ты предлагаешь это всё притащить в сборочную систему, да ещё в нагрузку со всеми UB, сегфолтами, мемориликами, трёхэтажными ошибками темплейтов, зацикливаниями и всеми остальным прелестями С++. Этого всего в сборочной системе быть не должно, а значит чистый С++ не подходит. Плюс не забывай, сборочная система в проекте это зачастую то, о чём заботятся меньше всего, по остаточному принципу. То есть качество кода там будет ниже, чем в основном проекте.

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

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

Мне так кажется, вы предлагаете лечить заикание вырыванием языка:

То есть с/с++ это логичный выбор.

Глядя на С++ код, очень редко встречаешь что-то читабельное.

а значит чистый С++ не подходит

влечёт за собой кучу других проблем, связанных с самим С++

Взамен мы полностью лишаемся удобной настройки проекта из гуйни Visual Studio и XCode.

Хорошее дело гуйнёй не назовут ;)

Если так важно иметь возможность настройки из Visual Studio и XCode, то можно сделать какой-то скрипт для их импорта/экспорта в симейк. Хотя я не понимаю, что ты там, каждый день крутишь настройки компиляции?

Обычно прописал один раз настройки и забыл…

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

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

https://github.com/coder137/build_in_cpp

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

Этакий build.cpp.

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

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

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

UPD. Поскольку пример по ссылке – убожество без хелперов, вот так выглядит cakefile.cpp одной из моих библиотечек.

Прикольно! А что понимается под хелперами? Это вспомогательные крестофункции, которые создают более сложные правила сборки под конкретные задачи (типа компила С++ проектов) через голый Make-like v.rule()? Берутся они из сошек вроде dimgel-svlen1[-DEBUG].so, dimgel-zs1-buildtime[-DEBUG].so?

А что понимается под хелперами? Это вспомогательные крестофункции […] через голый Make-like v.rule()?

Да, всё так. rCompile(), rLink*() – в самом <cake/aux.h>, а svlen1 и zs1 – это отдельные проекты, трансформаторы кода на clang libtooling.

	US<R> rrCompile(Oven& v, DirMaker& dm, const rrCompile_Params& pp) {
		US<R> objs;
		if (!pp.cpps.empty()) {
			objs.reserve(pp.cpps.size());
			for (auto& cpp : pp.cpps) {
				auto srcPfx    = pp.srcPfx   .ends_with('/') ? pp.srcPfx    : pp.srcPfx    + '/';
				auto targetPfx = pp.targetPfx.ends_with('/') ? pp.targetPfx : pp.targetPfx + '/';
				auto o = util::fs::changePrefixAndExt(srcPfx, targetPfx, cpp, "o");
				auto d = util::fs::changeExt(o, "d");
				objs += v.rule(o, parseDFile(v, {.cpp = cpp, .d = d, .o = o}) + pp.morePrereqs, {
					// ATTENTION: `o` is passed by value.
					{[&v, &dm, o] {
						if (v.verbose(Verbosity_Default)) {
							v.getLog().compile("%s", o.c_str());
						}
						dm.mkdirRecursive(util::fs::getParentDir(o));
					}},
					pp.cc + V<S>{"-o", o, cpp}
				});
			}
		}
		return objs;
	}

А где этот Cake можно скачать (в смысле исходный код)?

А где этот Cake можно скачать (в смысле исходный код)?

А нигде. Я в опен-сорц уже наигрался.

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

Редко вижу крестовика, который бы реально хорошо разбирался в c++…

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

Не-не-не.

c++ слишком объёмен для изучения, а система сборки должна быть универсальна и работать для любого языка.

c++ слишком объёмен для изучения, а система сборки должна быть универсальна и работать для любого языка.

Универсальных систем сборки со своим собственным велосипедным DSL и так уже наплодили хоть попой жуй. Может стоит теперь задуматься об узкоспециализированных системах сборки? Ну чтобы например сборочные скрипты для крестопроектов писать на тех же самых крестах, а не учить всратый CMake, который ни для каких других задач больше не пригодится? Например как build.rs в расте или Setup.hs в хаскеле.

В треде уже кидали годные примеры подобных скриптов сборки на С++. Да, для хелловорлдов они могут показаться оверкиллом по сравнению с несколькими строчками на CMake. Но как только логика сборки усложняется и размер CMake скриптов переваливает за несколько тысяч строчек, очень быстро начинает не хватать полноценного ЯП со статической типизацией и нормальной поддержкой в IDE.

Универсальных систем сборки со своим собственным велосипедным DSL и так уже наплодили

Ещё подкину wake. :)

Wake is a build orchestration tool and language.
If you have a build whose steps cannot be adequately expressed in make/tup/bazel/etc, you probably need wake.
If you don’t want to waste time rebuilding things that don’t need it, or that your colleagues already built, you might appreciate wake.

Пример:

package build_wake

from wake import _
from gcc_wake import _

# Prefer to use system utf8proc if available
def utf8proc variant = match (pkgConfig "utf8proc")
    Some x -> Pass x
    None -> vendor @here variant "2.2.0" `.*\.h|utf8proc_data\.c` `utf8proc\.c`

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

Одно это уже ногоу. Простые вещи должны делаться просто. Иначе не взлетит. Ты покажешь этот хеллоуворд и 99% покрутят пальцем у виска.

Одно это уже ногоу. Простые вещи должны делаться просто.

Т.е. ногоу для простых вещей. Вот пускай и делают простые вещи на чём-нибудь простом – например, тут выше упоминали тупо shell-скрипт с одной командой компиляции. Собственно, сам я так и делаю. А для вещей на полкопейки посложнее пишу простенький makefile.

Ну вот и сделали симэйк, которого хватает для 99% проектов. А если кому-то нужно что-то сложное, нестандартное пусть пишет свою собственную систему сборки на чём угодно, почему нет?

Ну чтобы например сборочные скрипты для крестопроектов писать на тех же самых крестах

В целом, здравая идея. В установочном комплекте такой системы сборки поставлять компилятор C++ и библиотеки с функциональностью, аналогичной той, что дает сейчас cmake. Конфигурирование происходило бы гораздо быстрее. И писать с наличием нормальных типов данных было бы удобнее.

Конфигурирование происходило бы гораздо быстрее. И писать с наличием нормальных типов данных было бы удобнее.

Именно. Как только объем CMake скриптов переваливает определенный порог, поддерживать их становится очень невесело. Полюбуйся например на тонны CMake скриптопараши в движке O3DE. Разрабы настолько задолбались с этим убогим высером, что от безысходности часть скриптов написали на питоне. Естественно у них есть отдельные папочки CMake скриптов под каждую платформу (Android, Linux, Mac, Windows, iOS), где лежит чуть ли не половина всех файлов. Кроссплатформенный CMake такой кроссплатформенный.

Глядя на этот ад, треш и израиль, лучше бы они конфигуратор на крестах написали, чесслово. Кстати когда-то давно видел самодельный С++ конфигуратор в одной либе. Вроде ClanLib, но за давностью лет могу ошибаться. Может старожилы подскажут.

Именно. Как только объем CMake скриптов переваливает определенный порог, поддерживать их становится очень невесело

Кроссплатформенный CMake такой кроссплатформенный.

Нормально их поддерживать. Если писать нормально.

Android, iOS

Это другая история. Там cmake не самодостаточен. Но я обратного не утверждал.

https://learn.microsoft.com/en-us/cpp/build/cmake-projects-in-visual-studio?v... CMake projects in Visual Studio

На habr блог есть об использовании Visual Studio для сборки под Linux.
...

Появится необходимость, буду разбираться.

«Бульба (исходники) ёсть, вода (Perl) радом. Пишем скрипт сборки на Perl и парадок».

Можно придумать какой-нибудь формат xml (или использовать уже готовый, например xml, содержащий проект для Visual Studio), содержащий метаданные для сборки.
Затем запускаем генератор, который, используя данные xml, создаёт сборочный скрипт (например на Perl).

содержащий метаданные для сборки.

Только под винду?

Затем запускаем генератор, который, используя данные xml, создаёт сборочный скрипт (например на Perl).

А кто бы это сделал? И не будет ли это сильно медленно по итогу собирать.

А кто бы это сделал?

Кто не поленится, тот и сделает.
Сложность решения этой задачи лишь одна - лень.

скриптопараши в движке O3DE

Мда… полистал это убожество. У меня ещё примеры были не такие адовые. Им следовало выкинуть нах этот кривой и убогий CMake и взять Waf, как сделали немцы из CryTek со своей огромной плюсовой базой: https://docs.cryengine.com/display/SDKDOC4/WAF+Build+System

Тогда бы они сразу писали на Python’е все свои сложные сборочки скрипты и конфигураторы без этой упоротой CMake-дрисни.

Тогда бы они сразу писали на Python’е все свои сложные сборочки скрипты и конфигураторы без этой упоротой CMake-дрисни.

И получили бы портянки с питоньей дриснёй, ибо упоротость разработчиков никуда бы не делась.

получили бы портянки с питоньей дриснёй

Они хотя бы:

1. Типизируются хинтами, имеют кучу валидаторов, линтеров, выправлялок синтаксиса и пр. батареек.
2. Имеют относительно нормальный человекочитаемый синтаксис вместо CMake-ссанины.
3. Для элементарных и частоиспользуемых в системе сборки вещей по типу заменить строку в файле, вызвать внешную утилиту, перебрать что-то в цикле там есть куча удобных и лаконичных конструкций.
4. Удобные dict/list/tuple и пр. примитивы которыми CMake до сих пор не обзавёлся и разработчики серьёзных библиотек как по ссылкам в этом треде вынуждены срать себе в каталоги cmake кривоработающими велосипедами.
5. Адекватный Pattern Matching, который много где пригодился бы в сборочных скриптах, делая их лаконичными.
6. Python для скриптования сегодня знают все и поддерживают все IDE, он используется как язык скриптования в куче инструментов.
7. Не нужно учить откровенно криво спроектированный DSL с овратительнейшим синтаксисом и виндузотной регистронезависимостью.

взять Waf

Он сам собирает? Или вызывает нижележащую систему сборки?

Сам.

Но там есть генерилки проектов для MSVC и XCode если требуется:

• https://gitlab.com/ita1024/waf/-/blob/master/waflib/extras/msvs.py?ref_type=heads
• https://gitlab.com/ita1024/waf/-/blob/master/waflib/extras/xcode6.py?ref_type=heads

А как его собственная скорость сборки по сравнению с той же VS или Ninja ?

Не думаю что будет быстрее Ninja, всё-таки Python.

Но каких-то бенчмарков я не нашёл, увы. А так было бы интересно посмотреть все эти Premake, Ninja, Bazel, Qbs, Make в сравнении между собой.

Пока из того, что я использовал (VS, Make, Nmake, Xcode, Ninja) на одних и тех же проектах Ninja быстрее всего.

Этакий build.cpp.

Кстати для scala есть sbt (стандарт де-факто, и не без причин). Его билд-скрипты пишутся на scala, императивные. Т.е. для какого-то специфического функционала, ради которого для maven пришлось бы писать отдельный проект-плагин, на sbt можно вшить всю логику в сам билд-скрипт.

использует std::filesystem::path вместо примитивных строк

Так себе преимущество: вся эта фигня просто БЕШЕНО тормозит. Гы, как и полагается сраной прослойке. Так что мой выбор – строки и syscalls (а точнее обёртки над ними, бросающие исключения).

Кстати для scala есть sbt (стандарт де-факто, и не без причин).

Прикольно, не знал, всегда думал что JVM-базед языки используют Maven или Gradle. Интересно, почему в ФП языках таки додумались до императивных скриптов сборки на тех же самых языках, а в мейнстриме - нет.

Так себе преимущество: вся эта фигня просто БЕШЕНО тормозит.

Сильно сомневаюсь, что оверхед от std::filesystem::path вообще будет заметен в сборочных скриптах, которые 99% времени тратят на ковыряние в файловой системе и вызовы компилятора с прочими утилитами. Зато std::filesystem::path - это отдельный типобезопасный класс без неявных преобразований в строчки с пачкой полезных методов. Мне например не хватает такого класса в культях. Там только строчки QString плюс помойка QFileInfo, в которую беспорядочно свалены как методы для работы с путями, так и собственно методы для получения информации о файлах.

Кстати для scala есть sbt (стандарт де-факто, и не без причин).

Прикольно,

Так что сформулированное EXL правило «в IT всегда становится негласным стандартом самое всратое решение» иногда-таки даёт сбой. :)

Хотя я конечно и sbt обосрать могу, да и саму скалу тоже, но это будет уже из серии «There are only two kinds of languages: the ones people complain about and the ones nobody uses» (c) Bjarne.

Если бы сборочные скрипты можно было бы удобно писать на самих крестах,

Будто кто-то тебе запрещает

В идеале крестам нужно что-то наподобие Cargo

Вспомнил про https://build2.org и их https://cppget.org.

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

Но да, у build2 этот же путь. :)

Вспомнил про https://build2.org и их https://cppget.org.

Ага, помню такое. Но эти ребята совсем упоролись и решили самостоятельно переписать сборку существующих С/C++ либ на свой собственный DSL. В отличие от рецептов Conan и vcpkg, которые просто дергают уже существующую систему сборки (CMake, autotools етц), в build2 походу берут сорцы, выковыривают из них оригинальную систему сборки и пишут свои скрипты с нуля. На мой взгляд, это путь в никуда. Они не смогут угнаться за авторами крестолиб и нормально поддерживать самописные скрипты. Они даже культи полностью не смогли портировать. У них в репозиториях есть только модули Qt Core, Qt Gui и Qt Widgets.

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

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

Это правда, я сам про конан не так давно узнал. Но сам факт того что пакетирование для С++ написано на питоне… напрягает если честно.

К тому же его до сих пор нет в Дебиане, а это плохой знак.

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

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

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

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

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

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

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