CMake 3.28

Годно, нужно.

В исходниках обнаружил полезный enum_set.

diff --git a/original/cmext/enum_set b/enum_set
index d7b8b39..e5ca9ea 100644
--- a/original/cmext/enum_set
+++ b/enum_set
@@ -11,8 +11,7 @@
 #include <iterator>
 #include <limits>
 #include <utility>
-
-#include <cm/type_traits>
+#include <type_traits>

 //
 // Class enum_set offers the capability to manage a set of enum values
@@ -111,7 +110,7 @@ private:

 template <
   typename Enum,
-  typename cm::enable_if_t<
+  typename std::enable_if_t<
     std::is_enum<Enum>::value &&
       std::is_unsigned<typename std::underlying_type<Enum>::type>::value,
     int> = 0>

Одно из самых больших нужно, наряду с Meson. Autotoolsокапец скоро наступит, надеюсь.

Ну, автотулзокапец пока не настанет, слишком много проектов на него завязано. А вот что такое вся эта нинзя с мезоном не есть понятно. И кто эту настроечно-сборочную систему понимает — тоже. Я так и не понял, ни как этим рулить, ни как этим пользоваться. Из разумного только cmake, походу.

вся эта нинзя с мезоном

Люто-бешено бурчу в унисон.

Да, вроде много кто на эту связку переполз из проектов с большой кодовой базой, типа QEMU с гномом, но я так понял, мезон все равно pkgconfig и настроечные модули cmake'a пользует. Ну и тогда нафига? Настроечные модули для cmake разработчики библиотек уже научились, вроде как, включать в поставку, а для этого чуда что делать? То ли он совсем зонтичный, типа натаскаем настроек отовсюду, докуда дотянемся, либо... На этом мысль останавливается.

Для Ninja есть GN с одной из лучших справок, которые я видел в консольных утилитах.

мезон все равно pkgconfig

А в muon pkgconfig встроен. Можно собрать и с поддержкой cURL. На C. :)

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

Господин-нонкомформист чем собирает?

Одно из самых больших нужно, наряду с Meson.

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

Если ты не знал, то автотулзы ничего не собирают. Это побочная ненужная нашлёпка на make.

Собственно, для сборки проектов из большого количества исходных файлов давным давно придумали make, а если файлов мало и они не используют некроссплатформенную экзотику и прочие сложности - в большинстве случаев достаточно одной шелл команды типа gcc -o binname *.c $CFLAGS $LDFLAGS.

Только qmake.

А вот что такое вся эта нинзя с мезоном не есть понятно.

Да в общем то и симейк точно так же нинзю может генерить. В чём претензия то?

И кто эту настроечно-сборочную систему понимает — тоже.

У мезона доки на высшем уровне. А что конкретно вам в нём непонятно?

мезон все равно pkgconfig и настроечные модули cmake’a пользует. Ну и тогда нафига?

Чего? пкгконфиг все используют, а какие ещё модули симейка? Что курили? :)

We will continue to support qmake for the lifetime of Qt 6, so there is no need to make any changes to your build system if you're using it, but we recommend to use CMake for all new projects

Пора уходить😔

А в muon pkgconfig встроен.

Пфф, а это ещё что? :)

muon - a meson-compatible build system

Да они там что, почкованием размножаются? Откуда он взялся, и зачем? :)

Одно другому не мешает, так пущай оба живут. Конкуренция между двумя хорошими продуктами на пользу обоим.

autotools / cmake / meson это всё одинаково ненужная блоатварь.

Так на каких системах сборки работают настоящие джедаи нынче? Просветите.

Откуда он взялся

Проекту больше трёх лет, здравствуйте.

и зачем?

Потому что на C и не зависит от Питона. А ещё muon можно скомпилировать со встроенным samurai.

мезон написан на питоне, мюон - на си, и бутстрапится с нуля (лишь бы был сишный компилятор).

Была бы очень здравая затея, если бы мезон в принципе был нужен

Это Вы недокурили. А вот это что такое?

ls /usr/share/cmake-3.22/Modules/
AddFileDependencies.cmake                     CMakeDetermineASM_MASMCompiler.cmake                            CMakeTestCCompiler.cmake            FindGTK.cmake                        FindRuby.cmake
AndroidTestUtilities                          CMakeDetermineASM_NASMCompiler.cmake                            CMakeTestCompilerCommon.cmake       FindHDF5.cmake                       FindSDL.cmake
AndroidTestUtilities.cmake                    CMakeDetermineCCompiler.cmake                                   CMakeTestCSharpCompiler.cmake       FindHg.cmake                         FindSDL_image.cmake
BasicConfigVersion-AnyNewerVersion.cmake.in   CMakeDetermineCompileFeatures.cmake                             CMakeTestCUDACompiler.cmake         FindHSPELL.cmake                     FindSDL_mixer.cmake
BasicConfigVersion-ExactVersion.cmake.in      CMakeDetermineCompilerABI.cmake                                 CMakeTestCXXCompiler.cmake          FindHTMLHelp.cmake                   FindSDL_net.cmake
BasicConfigVersion-SameMajorVersion.cmake.in  CMakeDetermineCompiler.cmake                                    CMakeTestFortranCompiler.cmake      FindIce.cmake                        FindSDL_sound.cmake
BasicConfigVersion-SameMinorVersion.cmake.in  CMakeDetermineCompilerId.cmake                                  CMakeTestGNU.c                      FindIconv.cmake                      FindSDL_ttf.cmake
.......

И некоторые библиотеки типа той же Poco с собой настройки для cmake тащат.

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

Да в общем то и симейк точно так же нинзю может генерить. В чём претензия то?

make и так есть, генеренные мейкфайлы и сборка out-of-tree меня вполне устраивают. Нахрена что-то еще-то?

Проекту больше трёх лет, здравствуйте.

Да на самом то деле и мезон в 1.0 вышел только год как. А до этого, он был весьма маргинальным.

Потому что на C и не зависит от Питона. А ещё muon можно скомпилировать со встроенным samurai.

Атака клонов какая-то. :) Пойду гляну…

Тебя и EXL кто-то заставляет пользоваться cmake?

Тогда Maven/sbt

Нахрена что-то еще-то?

https://github.com/llvm/llvm-project/tree/main/llvm/utils/gn

The main motivation behind the GN build is that some people find it more convenient for day-to-day hacking on LLVM than CMake. Distribution, building just parts of LLVM, and embedding the LLVM GN build from other builds are non-goals for the GN build.

This is a good overview of GN.

Да может и так. Ниньзя мне не нужен. Как писать CMakeLists я знаю, как писать configure.ac на m4 — тоже. А как этой хренью пользоваться — нет. А главное, не знаю, что в ней есть такого, чего мне не хватает в autotools и cmake. Пока всего хватало.

мезон написан на питоне, мюон - на си, и бутстрапится с нуля (лишь бы был сишный компилятор).

Понять бы ещё, какие фичи из современного мезона в нём реализованы… Видимо, чтобы это понять, придётся немного палочкой потыкать. Чем и займусь.

Была бы очень здравая затея, если бы мезон в принципе был нужен

Да я даже не знаю, что, по вашему, тогда нужно…

Это Вы недокурили. А вот это что такое?

Не совсем понял, что вы хотите мне сказать. Вы сказали, что, дословно: «мезон все равно pkgconfig и настроечные модули cmake’a пользует.»

Из того, что вы тут показали, как-то следует, что это всё использует мезон?

Ну может быть... Что называется, дело вкуса.

Есть make - программа для парсинга мейкфайла и выполнения рецептов из него. У неё есть некоторые недостатки, но общая идеология её работы полностью правильная.

Так мейк - и не система сборки. Более того, различные системы сборки умеют генерить мейк-файлы. Хотя нынче, в основном, генерят нинжу, по тому, что она быстрее работает.

Нет, без системы сборки, на голом мейке, тоже можно… При условии 1 единственной целевой системы, где ничего не меняется, все зависимости всегда на месте и их версии одни и те же всегда. Для хелло ворлда подойдёт.

make и так есть, генеренные мейкфайлы и сборка out-of-tree меня вполне устраивают. Нахрена что-то еще-то?

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

Как заставить это поделие создать несколько разных исполняемых файлов? А то я неосилятор. В CMake и в мейкфайлах с этим никаких проблем.

Типа этого?

https://stackoverflow.com/questions/1538398/how-do-i-use-qmake-to-build-multiple-binaries-in-a-single-project

Об этом явно сказано в документации мезона. См. cmake subprojects. Я, может, чего не понял, читал все по верхам. Мне что-то показалось, что мезон пытается настройки сборки из модулей симейка вытащить, если их найдет. Ладно, забейте, я все равно этой кучей питоновского говна пользоваться пока не хочу. Может когда придется, тогда и буду разбираться. Пока не нужно.

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

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

для сборки проектов из большого количества исходных файлов давным давно придумали make

Господи, да почему же сишники такие луддиты? Ты что-нибудь сложнее хелловорлдов когда-нибудь писал? Ну чтобы несколько сотен файлов и с поддержкой инкрементальной сборки. Боюсь представить размер makefile портянки и её сложность поддержки. За попытку собирать проект самописным makefile нужно увольнять.

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

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

Там в «Related» может быть что-то попроще.

Была надежда на светлое будущее с декларативным QBS. Но как оно обычно бывает победили всратые реализации, а qbs похоронили.

Пора уже привыкнуть, что в IT всегда становится негласным стандартом самое всратое решение. Worse is better.

Уж C++-программисты могли себе сделать нормальную систему сборки, а сделали угрёбищный CMake, бгг.

qbs похоронили

Живёт и здравствует: https://github.com/qbs/qbs

полезный enum_set

А когда в самом убогом DSL’е у CMake обнаружится этот enum_set, чтобы проекты не городили такие вот костыли:

https://github.com/raysan5/raylib/blob/master/cmake/EnumOption.cmake

Для использования подобных конструкций, которые как бы ожидаются в любой адекватной системе сборке, кроме CMake?

enum_option(PLATFORM "Desktop;Web;Android;Raspberry Pi;DRM" "Platform to build for.")

enum_option(OPENGL_VERSION "OFF;4.3;3.3;2.1;1.1;ES 2.0;ES 3.0" "Force a specific OpenGL Version?")

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

Это же compile-time enum_set. Мало ли каких опций добавит автор проекта.

Ну смейк тоже умеет

Не сомневаюсь. Симейк много чего умеет, а мезон пока в догоняющих.

но эта фича не хороша

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