CMake 3.28

А вот это что такое?

FindSDL.cmake
FindGTK.cmake
FindSDL_image.cmake
FindSDL_mixer.cmake

А это древний CMake’овский кал по поиску всяких SDL1, GTK+2 и прочего уже редкоиспользуемого, который они перестали обновлять, но всё ещё таскают с собой.

https://github.com/Kitware/CMake/pull/152#issuecomment-99841783

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

А когда в самом убогом DSL’е у CMake обнаружится этот enum_set

Когда ты перестанешь ныть

Я ж сказал, мне казалось, что мезон сильно зонтичный и вытаскивает опции для строчки того же линковщика откуда может. Есть pkgconfig, есть настроечные модули симейка, которые многие с собой тащят, а настроечных макросов для мезона, насколько я понимаю, пока нет, самому приходится справляться. Поэтому, я и предположил, что для определения имен и версий библиотек мезону надо брать информацию откуда придется. В частности, из симейка. Ну нет, так нет. Хрен с ним. Если оставить в стороне вкусовщину на тему синтаксиса сборочных файлов, я не вижу причин уходить с того же cmake в сторону meson. Причины не использовать автотулз в пользу cmake есть.

Ну и что? Я за их обещаниями не слежу. Поинт в той дискуссии был другой. Может когда и зачистят.

Я вот тоже нифига не понял кто такой ninja, и почему он связан с cmake’ом.

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

Ну вот по идее то, пкгконфига должно хватать. Зачем симейковские потроха народ таскает - мне не ведомо. Если знаете, просветите.

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

Так и что толку в том что в исходники CMake завезли какой-то там enum_set для их внутренней кухни, если в сам CMake DSL до сих пор не прокинуто ничего по типу велосипедного enum_option:

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

Который накостылил себе каждый проект имевший несчастье связаться с CMake?

Где профит-то? Тем более CMake’овский enum-велосипед в теории должен подмениться на такие вот подобные штуки из стандарта в будущем:

• https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4428.pdf
• https://aantron.github.io/better-enums/demo/C++17ReflectionProposal.html

Ну так потому, что как я понял, cmake-package для себя еще не все написали. А многие уже и не напишут. Та же проблема, что и у мезона — под него инфраструктуры нет. Макросы для autoconf научились писать многие, cmake-package — тоже, а для мезона никто и не почесался, походу.

Потому что на C и не зависит от Питона.

Послушайте, сэр, я тут вам скажу кое что, только не обижайтесь… :)

$ sudo apt install muon
Будут установлены следующие дополнительные пакеты:
  apt-xapian-index debconf-kde-data debconf-kde-helper gamin kactivities-bin
  kactivitymanagerd kde-cli-tools kde-cli-tools-data kded5 kio
  kpackagelauncherqml kpackagetool5 kwayland-data kwayland-integration
  libdbusmenu-qt5-2 libdebconf-kde1 libgamin0 libhfstospell11
  libkf5activities5 libkf5archive-data libkf5archive5 libkf5attica5
  libkf5auth-data libkf5auth5 libkf5authcore5 libkf5codecs-data libkf5codecs5
  libkf5completion-data libkf5completion5 libkf5config-bin libkf5config-data
  libkf5configcore5 libkf5configgui5 libkf5configwidgets-data
  libkf5configwidgets5 libkf5coreaddons-data libkf5coreaddons5 libkf5crash5
  libkf5dbusaddons-bin libkf5dbusaddons-data libkf5dbusaddons5
  libkf5declarative-data libkf5declarative5 libkf5doctools5
  libkf5globalaccel-bin libkf5globalaccel-data libkf5globalaccel5
  libkf5globalaccelprivate5 libkf5guiaddons-bin libkf5guiaddons-data
  libkf5guiaddons5 libkf5i18n-data libkf5i18n5 libkf5iconthemes-bin
  libkf5iconthemes-data libkf5iconthemes5 libkf5itemmodels5
  libkf5itemviews-data libkf5itemviews5 libkf5jobwidgets-data
  libkf5jobwidgets5 libkf5kcmutils-data libkf5kcmutils5 libkf5kcmutilscore5
  libkf5kiocore5 libkf5kiogui5 libkf5kiontlm5 libkf5kiowidgets5
  libkf5kirigami2-5 libkf5newstuffcore5 libkf5notifications-data
  libkf5notifications5 libkf5package-data libkf5package5 libkf5parts-data
  libkf5parts-plugins libkf5parts5 libkf5plasma5 libkf5pty-data libkf5pty5
  libkf5quickaddons5 libkf5runner5 libkf5service-bin libkf5service-data
  libkf5service5 libkf5solid5 libkf5solid5-data libkf5sonnet5-data
  libkf5sonnetcore5 libkf5sonnetui5 libkf5su-bin libkf5su-data libkf5su5
  libkf5syndication5abi1 libkf5textwidgets-data libkf5textwidgets5
  libkf5threadweaver5 libkf5wallet-bin libkf5wallet-data libkf5wallet5
  libkf5waylandclient5 libkf5widgetsaddons-data libkf5widgetsaddons5
  libkf5windowsystem-data libkf5windowsystem5 libkf5xmlgui-bin
  libkf5xmlgui-data libkf5xmlgui5 libkwalletbackend5-5 libkworkspace5-5
  libpolkit-qt5-1-1 libqapt3 libqapt3-runtime libqca-qt5-2
  libqca-qt5-2-plugins libqt5qmlworkerscript5 libqt5quickcontrols2-5
  libqt5quickshapes5 libqt5quicktemplates2-5 libqt5quickwidgets5
  libqt5texttospeech5 libvoikko1 libxapian30 libxcb-record0 python3-xapian
  qml-module-org-kde-kcm qml-module-org-kde-kcmutils
  qml-module-org-kde-kirigami2 qml-module-org-kde-kitemmodels
  qml-module-org-kde-kquickcontrolsaddons qml-module-org-kde-newstuff
  qml-module-org-kde-runnermodel qml-module-qtgraphicaleffects
  qml-module-qtqml qml-module-qtqml-models2 qml-module-qtquick-controls
  qml-module-qtquick-controls2 qml-module-qtquick-layouts
  qml-module-qtquick-shapes qml-module-qtquick-templates2
  qml-module-qtquick-window2 qml-module-qtquick2 qtspeech5-speechd-plugin
  software-properties-qt sonnet-plugins systemsettings
Предлагаемые пакеты:
  voikko-fi xapian-tools xapian-doc hspell
Следующие НОВЫЕ пакеты будут установлены:
  apt-xapian-index debconf-kde-data debconf-kde-helper gamin kactivities-bin
  kactivitymanagerd kde-cli-tools kde-cli-tools-data kded5 kio
  kpackagelauncherqml kpackagetool5 kwayland-data kwayland-integration
  libdbusmenu-qt5-2 libdebconf-kde1 libgamin0 libhfstospell11
  libkf5activities5 libkf5archive-data libkf5archive5 libkf5attica5
  libkf5auth-data libkf5auth5 libkf5authcore5 libkf5codecs-data libkf5codecs5
  libkf5completion-data libkf5completion5 libkf5config-bin libkf5config-data
  libkf5configcore5 libkf5configgui5 libkf5configwidgets-data
  libkf5configwidgets5 libkf5coreaddons-data libkf5coreaddons5 libkf5crash5
  libkf5dbusaddons-bin libkf5dbusaddons-data libkf5dbusaddons5
  libkf5declarative-data libkf5declarative5 libkf5doctools5
  libkf5globalaccel-bin libkf5globalaccel-data libkf5globalaccel5
  libkf5globalaccelprivate5 libkf5guiaddons-bin libkf5guiaddons-data
  libkf5guiaddons5 libkf5i18n-data libkf5i18n5 libkf5iconthemes-bin
  libkf5iconthemes-data libkf5iconthemes5 libkf5itemmodels5
  libkf5itemviews-data libkf5itemviews5 libkf5jobwidgets-data
  libkf5jobwidgets5 libkf5kcmutils-data libkf5kcmutils5 libkf5kcmutilscore5
  libkf5kiocore5 libkf5kiogui5 libkf5kiontlm5 libkf5kiowidgets5
  libkf5kirigami2-5 libkf5newstuffcore5 libkf5notifications-data
  libkf5notifications5 libkf5package-data libkf5package5 libkf5parts-data
  libkf5parts-plugins libkf5parts5 libkf5plasma5 libkf5pty-data libkf5pty5
  libkf5quickaddons5 libkf5runner5 libkf5service-bin libkf5service-data
  libkf5service5 libkf5solid5 libkf5solid5-data libkf5sonnet5-data
  libkf5sonnetcore5 libkf5sonnetui5 libkf5su-bin libkf5su-data libkf5su5
  libkf5syndication5abi1 libkf5textwidgets-data libkf5textwidgets5
  libkf5threadweaver5 libkf5wallet-bin libkf5wallet-data libkf5wallet5
  libkf5waylandclient5 libkf5widgetsaddons-data libkf5widgetsaddons5
  libkf5windowsystem-data libkf5windowsystem5 libkf5xmlgui-bin
  libkf5xmlgui-data libkf5xmlgui5 libkwalletbackend5-5 libkworkspace5-5
  libpolkit-qt5-1-1 libqapt3 libqapt3-runtime libqca-qt5-2
  libqca-qt5-2-plugins libqt5qmlworkerscript5 libqt5quickcontrols2-5
  libqt5quickshapes5 libqt5quicktemplates2-5 libqt5quickwidgets5
  libqt5texttospeech5 libvoikko1 libxapian30 libxcb-record0 muon
  python3-xapian qml-module-org-kde-kcm qml-module-org-kde-kcmutils
  qml-module-org-kde-kirigami2 qml-module-org-kde-kitemmodels
  qml-module-org-kde-kquickcontrolsaddons qml-module-org-kde-newstuff
  qml-module-org-kde-runnermodel qml-module-qtgraphicaleffects
  qml-module-qtqml qml-module-qtqml-models2 qml-module-qtquick-controls
  qml-module-qtquick-controls2 qml-module-qtquick-layouts
  qml-module-qtquick-shapes qml-module-qtquick-templates2
  qml-module-qtquick-window2 qml-module-qtquick2 qtspeech5-speechd-plugin
  software-properties-qt sonnet-plugins systemsettings
Обновлено 0 пакетов, установлено 147 новых пакетов, для удаления отмечено 0 пакетов, и 0 пакетов не обновлено.
Необходимо скачать 22,6 MB архивов.
После данной операции объём занятого дискового пространства возрастёт на 123 MB.
Хотите продолжить? [Д/н]

ЧОООО? Да вы совсем там охренели? Это и есть ваш мюон? :)

Ну и что?

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

https://github.com/raysan5/raylib/tree/master/cmake

Из разумного только cmake, походу.

Где здесь разумность если ты вынужден пердолить то что по ссылке выше? CMake-ублюдок это ещё одна личина autotools’ов, просто в гламурной обёртке, вот и всё.

Где профит-то?

Профит в использовании enum_set в моём внутреннем камбузе. :)

Это другой muon! :)

Homepage: https://projects.kde.org/projects/kde/workspace/muon
Muon is a graphical package manager.

Это и есть ваш мюон? :)

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

apt тебе на запрос muon выдал какую-то там GUI’шную KDE’шную перделку-присралку к пакетному менеджеру, тогда как то что тебе нужно лежит тут и на чистой сишке: https://github.com/annacrombie/muon

Это другой muon! :)

Аррр… окей. :) muon-meson называется тот, что нужен… Ладно, попытка номер 2.

Этот EXL порвался, несите другого😁

Да и ладно. CMake — действительно более удобная замена автотулзам. И не больше. И это хорошо. Возможно, у меня простые потребности, но ничего из этого мне пока не потребовалось. Лучше напердолить это самому, если надо, чем надеяться на кривые руки питонят. Так или иначе, пердолить это все равно приходится. Не макросами симейка, так кодом на питоне. Так какая разница?

Профит в использовании enum_set в моём внутреннем камбузе. :)

Ну да, я и говорю – внутрянняя кухня.

Потому что с выходом нового CMake вот это проектное велосипедирование разработчиков enum’ов: https://github.com/raysan5/raylib/blob/master/cmake/EnumOption.cmake никак не отпадает. Они всё ещё вынуждены писать эти кривоработающие костыли, чтобы сделать CMake хоть как-то юзабельным для их нужд.

Макросы для autoconf научились писать многие, cmake-package — тоже, а для мезона никто и не почесался, походу.

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

что такое вся эта нинзя

Вспомнил, что есть модуль для premake, со многими ToDo: https://github.com/jimon/premake-ninja

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

Пишу я в 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 файлы для пкгконфига?

То я в шутку больше. На самом деле, его хвалят. Meson не пытается вытесять сабж, это один из стандартных способов сборки сабпроджектов и разрешения зависимостей. Это очень удобно, собирать нужные либы минимально меняя CMakeLists.txt, не переписывая полностью сборку на meson. Также хорош в плане сборки кроссплатформенных проектов на 3-4 разных языках (СМake в этом плане так себе). Есть, конечно, и свои минусы вроде переопределения путей и еще парочки, но остальные грабли решаемы, в принципе.

Это другой muon! :)

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

meson.build:83:7: error invalid kwarg: 'env'
meson.build:24:3: error invalid kwarg: 'dependencies'
 24 |   dependencies: declare_dependency(

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

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

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

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

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

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

собирать надо потом нинжой

$ muon version

muon 0.2.0-8d397263
meson compatibility version 1.1.99
enabled features:
  libcurl
  libpkgconf
  libarchive
  samurai <- это нужно разрешать в опциях

он моделирует поведение какой-то из ранних версий мезона

Да.

Ну вероятно. У симейка есть требование указать язык сборки.

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

на практике даёт наибольшую мощность за наименьшее количество усилий.

И именно поэтому проект systemd выбрал Meson вместо CMake.

А если модулей для пкгконфа не предоставили? Вот как 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 фазу вошёл год назад), может статься так, что симейковские старпё^^стартаперы нас и задавят. :)

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

Кстати, 22-го ноября вышел pkgconf 2.1.0. hobbit, если это было не слишком давно, напишу новость.

Думаю, можно.

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

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

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

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

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

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

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

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

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

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

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

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

Для меня и 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 папочку.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Так мейк - и не система сборки.

Так и я о том. Блоатвари, которые приняты называть «системами сборки», не нужны, нужен парсер рецептов, коим является make.

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

Ну это наглое враньё. Либо профнепригодность. Единственная из мейнстримных ОС, где вообще всё не так - это винда (там и make обычно нет а есть всякие visual studio), для неё (если она нужна) можно сделать и файл проекта под vs. Всё остальное компилится примерно единообразно, а отличия между системами по месту делаются ifdef-ами и небольшим набором конфигов компиляции (не путать с той чушью, которую делают автотулзы, выясняя наличие в системе функции snprintf и подобного - это было актуально 40 лет назад).