LINUX.ORG.RU

CMake 3.28

 , , , ,

CMake 3.28

1

3

6 декабря состоялся выпуск 3.28 кроссплатформенной системы сборки CMake, написанной на языке C++ и распространяемой по лицензии BSD-3.

Список основных изменений:

  • улучшена поддержка модулей C++20 в генераторах Ninja и Visual Studio (VS 2022 и новее). Подробности в cmake-cxxmodules(7);
  • код языка HIP для GPU NVIDIA теперь может быть скомпилирован компилятором nvcc (NVIDIA CUDA Compiler). Подробности в описании переменной CMAKE_HIP_PLATFORM;
  • удалена команда exec_program(), признанная устаревшей в CMake 3.0. Вместо неё следует использовать execute_process();
  • сгенерированные файлы в целях, использующих наборы файлов, теперь по умолчанию считаются приватными. Генерируемые публичные заголовочные файлы должны быть указаны с помощью наборов файлов. Это позволяет создавать более эффективные графы сборки для Ninja. Подробности в политике CMP0154;
  • команды find_library(), find_path() и find_file() больше не ищут в префиксах установки, полученных из переменной окружения PATH. Это поведение было добавлено в CMake 3.3 для поддержки сред разработки MSYS и MinGW («MSYSTEM») в Windows и могло искать нежелательные префиксы, которые случайно оказались в PATH по каким-либо причинам.
  • добавлена поддержка директорий .xcframework для платформ Apple.

>>> Полный список изменений

★★★★★

Проверено: hobbit ()
Последнее исправление: hobbit (всего исправлений: 1)

Ответ на: комментарий от gns

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

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

EXL ★★★★★
()
Ответ на: комментарий от EXL

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

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

NickNotNick
()
Ответ на: комментарий от anonmyous

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

gns ★★★★★
()
Ответ на: комментарий от EXL

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

gns ★★★★★
()
Ответ на: комментарий от gns

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

Camel ★★★★★
()
Ответ на: комментарий от gns

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

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

anonmyous ★★
()
Ответ на: комментарий от dataman

Это же 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-велосипед в теории должен подмениться на такие вот подобные штуки из стандарта в будущем:

EXL ★★★★★
()
Ответ на: комментарий от anonmyous

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

gns ★★★★★
()
Ответ на: комментарий от dataman

Потому что на 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.
Хотите продолжить? [Д/н]

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

anonmyous ★★
()
Ответ на: комментарий от gns

Ну и что?

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

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

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

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

EXL ★★★★★
()
Ответ на: комментарий от anonmyous

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

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

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

EXL ★★★★★
()
Последнее исправление: EXL (всего исправлений: 1)
Ответ на: комментарий от dataman

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

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

anonmyous ★★
()
Ответ на: комментарий от EXL

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

gns ★★★★★
()
Ответ на: комментарий от dataman

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

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

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

EXL ★★★★★
()
Ответ на: комментарий от gns

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

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

anonmyous ★★
()
Ответ на: комментарий от anonmyous

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

Пишу я в 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
......

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

gns ★★★★★
()
Последнее исправление: gns (всего исправлений: 1)

Г-но, но приходится использовать.

snizovtsev ★★★★★
()
Ответ на: комментарий от gns

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

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

anonmyous ★★
()
Ответ на: комментарий от gns

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

Gonzo ★★★★★
()
Ответ на: комментарий от dataman

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

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

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

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

anonmyous ★★
()
Ответ на: комментарий от EXL

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

intelfx ★★★★★
()
Ответ на: комментарий от anonmyous

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

gns ★★★★★
()
Ответ на: комментарий от Gonzo

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

gns ★★★★★
()
Ответ на: комментарий от gns

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

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

anonmyous ★★
()
Ответ на: комментарий от anonmyous

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

$ muon version

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

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

Да.

dataman ★★★★★
() автор топика
Последнее исправление: dataman (всего исправлений: 1)
Ответ на: комментарий от gns

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

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

anonmyous ★★
()
Ответ на: комментарий от intelfx

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

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

EXL ★★★★★
()
Последнее исправление: EXL (всего исправлений: 1)
Ответ на: комментарий от anonmyous

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

gns ★★★★★
()
Ответ на: комментарий от gns

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

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

anonmyous ★★
()
Ответ на: комментарий от gns

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

А если модулей для 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/

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

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

EXL ★★★★★
()
Последнее исправление: EXL (всего исправлений: 3)
Ответ на: комментарий от EXL

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

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

anonmyous ★★
()
Ответ на: комментарий от dataman

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

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

dataman ★★★★★
() автор топика
Ответ на: комментарий от EXL

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

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

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

NickNotNick
()
Ответ на: комментарий от anonmyous

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

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

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

EXL ★★★★★
()
Ответ на: комментарий от EXL

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

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

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

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

gns ★★★★★
()
Ответ на: комментарий от EXL

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

gns ★★★★★
()
Ответ на: комментарий от anonmyous

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

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

gns ★★★★★
()
Ответ на: комментарий от NickNotNick

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

А почему я должен выполнять работу за инфантильных лентяев из 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 папочку.

EXL ★★★★★
()
Ответ на: комментарий от gns

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

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

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

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

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

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

anonmyous ★★
()
Ответ на: комментарий от NickNotNick

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

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

EXL ★★★★★
()
Последнее исправление: EXL (всего исправлений: 1)
Ответ на: комментарий от EXL

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

gns ★★★★★
()
Ответ на: комментарий от EXL

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

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

NickNotNick
()
Ответ на: комментарий от anonmyous

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

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

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

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

firkax ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.