Meson build system: более лучшего ещё не завезли?

CMake 3

2-я версия была трешовая и осадочек остался, это да.

meson … ну молодцы, конечно, в качестве подпирающей в попу альтернативы симейку вапще отлично, но так чтобы майндченджер, шоураннер и геймэндер - так нет.

Я такого не знаю. Сейчас идеал - CMake, но Meson где-то может быть проще пока не столкнёшься с его ограничениями.

Сборка проекта на плюсах

С Мезоном опыт пока что хороший: очень хорошо им собирать кроссплатформенные проекты, да на 3-4 разных языках

cmake в этом плане ну такое, кмк

Сейчас идеал - CMake

Бггг.

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

Плюсом, meson и не пытается вытесять CMake: это один из стандартных способов сборки сабпроджектов и разрешения зависимостей. Это очень удобно, собирать нужные либы минимально (или вообще не) меняя CMakeLists.txt, не переписывая полностью сборку на meson.

Всегда был лучше всех Qbs. Остальное лютая дичь, тупые генерилки и прокладки.

нет системы сборки кроме автотулзов

Если функционала Meson хватает, то лучше его брать.

CMake 3

На него уже появилась вменяемая документация?

вменяемая книжка, что может быть лучше

https://cliutils.gitlab.io/modern-cmake/modern-cmake.pdf

не появилось ли за последние годы что-то аналогичное по сути, но ещё более лучшее?

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

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

Так что тикайте на Мезон, хлопцы, потом расскажете, что да как. :)

По синтаксису мне больше всего, внезапно, понравился Bazel от Google

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

pip install cmake

Интересный метод дистрибуции.

Оно всё еще на Сях написано?

Languages

C 43.8%

C++ 29.1%

CMake 24.5%

Roff 0.8%

Shell 0.5%

Vim Script 0.4%

Other 0.9%

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

Вот и говорю, что интересный метод дистрибуции

Появилась пару лет назад https://crascit.com/professional-cmake/

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

Premake хоть и сделан с помощью lua у него к сожалению примерно та же история, без танцев с бубном qt не подключить и поддержку ninja вместо make так и не завезли.

А на большинство остальных аналогов cmake без слёз не взглянешь.

Остаётся два варианта: ждать когда окончательно отполируют cmake/meson, либо пилить свою систему сборки с блэкджеком и сами знаете кем на основе ninja.

на основе ninja

Мезон так-то не только ninja поддерживает

А на большинство остальных аналогов cmake без слёз не взглянешь.

Есть Jam.

либо пилить свою систему сборки

Все уже давно придумано - QBS решение всех проблем вообще.

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

У jam был шанс, но бустеры от него давно отказались в пользу cmake и bash скриптов. Почему? Я не в курсе.

The Qt Company announced that it will discontinue the further development of Qbs by the end of 2019 deprecated. The project is maintained by the community as part of the Qt Project.

Сначала был заменён на qmake с более адекватным синтаксисом, но тот оказался слишком медленным и большинство переползло на cmake.

Хотя бы напиши, что там такого особенного в нём и почему его стоит использовать.

Сначала был заменён на qmake с более адекватным синтаксисом

Ложь. QMake существовал в экосистеме Qt c первых моментов создания этого фреймворка, до эпохи Qt 3 он назывался tmake. Про адекватный синтаксис я промолчу, потому что в QMake синтаксис неадекватный, например, захардкоженный стиль размещения фигурных скобок.

тот оказался слишком медленным и большинство переползло на cmake.

Ложь. Причины перехода Qt на CMake совсем другие и выделены в статье по ссылке ниже вместе с упоминанием причин того, почему не выбрали свой собственный QBS. Насчёт быстроты работы, я уверен что QMake работает намного быстрее CMake, потому что пока в этом CMake распарсится его лапша на наркоманском DSL, создадуться горы каких-то дегенеративных скриптов (запахло autotools’ом) простой как палка QMake уже породит рабочий Makefile.

Qt переходит с qmake на CMake

Хотя бы напиши, что там такого особенного в нём и почему его стоит использовать.

1. QBS собирает сам (быстро и интелелктуально).

2. Синтаксис декларативный с элементами JS. Каждая сущность является объектом с набором неких свойств.

3. Самодостаточен (занимает 30 МБ).

4. Гибкий. Можно писать свои правила сборки легко и непринужденно.

5. Простой, поддерживает дохрена архитектур и компиляторов.

6. Содержит всего около 6-8 объектов про которые нужно по идее знать.

7. Документация простая и лаконичная, нет тонн смакеговна.

8. Парсит сам все инклюды, предефинед макросы и пр. для интеграции с IDE.

9. Очень простой и богатый API для интеграции с любой IDE.

10. Легко расширяем и легко фиксить баги… т.к. оно на JS то иногда достаточно поправить что-то в нужном JS уже установленного QBS чем ждать когда кто-то пофиксит.

11. Имеет генераторы для проектов для MSBuild, IAR EW, KEIL (если уж очень нужно, но обычно не нужно).

12. Например, приложение и либа описываются так:

== lib.qbs ==

DynamicLibrary {
   name: "mylib"
   files: ["foo.c"] 
}

== app.qbs ==

CppApplication {
   Depends { name: "mylib" }
   name: "myapp"
   files: ["main.c"] 
}

и сравните с говном на мезоне или смаке.

13. Гибкость умопомрачительная просто:

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

14. Одна идеология которой пронизан весь QBS очень простая, благодаря ей можно сделать все что угодно.

15. Попробуй на смаке собрать приложение для Андройда или иОС так же просто как на QBS (до сих пор в смаке говно-лапша из хз чего).

но тот оказался слишком медленным и большинство переползло на cmake.

о дооо.. конечно конечно… сравним?

причина банальна - эффективный менеджмент.

уже спустя столько времени после выхода Qt6 - до сих пор народ мучается с смакой-какакой. видели говноскрипты и костыли? :))

ЗЫ: А QBS как развивался так и развивается, скоро в конце марта (к QtC 7) выйдет релиз QBS 1.22…

более лучшее?

QBS же

Да qmake уже был и сильно обогнал по популярности qbs, поэтому большую часть усилий перевели на поддержку qmake, а затем и cmake. От qbs отказались как от неудавшегося проекта.

Ты на полном серьёзе готов заявить, что qmake работающий на основе gnu make, обгонит современный cmake 3.22 с генератором ninja? Ну или хотя бы meson.

Qbs

Deprecation of Qbs

Qt 6 - поддержка qmake продлиться до конца шестой версии qt, буду ли продолжать поддержку не ясно.

Я так и не увидел чем QBS-говно, которое выбросили на свалку лучше Meson.

а что не так со справкой с офсайта? Там описаны все команды и их опции, что еще надо?

Ты на полном серьёзе готов заявить, что qmake работающий на основе gnu make, обгонит современный cmake 3.22 с генератором ninja? Ну или хотя бы meson.

Я на полном серьёзе готов заявить, что генерация Makefile с помощью QMake и сборка им проекта обгонит современный CMake с его генератором Makefile по очевидным причинам: порождаемый Makefile у QMake прост как палка и редактируется руками, а CMake порождает разжиревший Makefile с хипстерским bloatware вроде цветных сообщений, сборочных процентов (которые адекватно не работают) и кучей другого бесполезного хлама.

Впрочем, нет смысла сравнивать то, что давно уже отправляется на покой: QMake и Makefile (make). Я лишь указал на ложные высказывания в твоём предложении.

Сейчас гораздо интреснее было бы сравнить CMake с его кучей наркоманской лапшевидной DSL-убогодрисни, Meson с его кучей Python’а и QBS с его кучей JavaScript и Qt и пр. вроде Premake на сборочной системе Ninja, если у них нет своей собственной.

Ну вот, уже хоть что-то, значит с этой штукой ещё можно жить.

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

QBS собирает сам (быстро и интелелктуально).

Хотелось бы сравнить этот момент в тестах с ninja.

Самодостаточен (занимает 30 МБ).

Вот это уже хорошо. Но большого преимущества не даёт.

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

Я не пытаюсь оправдать cmake, да у него есть косяки, но в целом их хотя бы местами пытаются исправить, новые версии активно выходят. И да простенький проект на qmake у меня по крайней мере в 2017 году собирался раза в 1.5-2 дольше, чем на cmake с make генератором.

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

Голый Make сильно устарел и без сторонних тулз еле шевелится, хорошо что появился ninja, который действительно способен собирать проекты в 2 раза быстрее, а то и больше.

Мне вот интересно чем же ты сам собираешь проекты? Если это конечно не секрет и не военная тайна.

Мне вот интересно чем же ты сам собираешь проекты? Если это конечно не секрет и не военная тайна.

На CMake, который вызывает каждый раз отвращение при использовании, точно такое же, какое раньше вызывал autotools.

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

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

Тот же Red Hat для критически важных компонентов инфраструктуры Linux (systemd, X.Org, Wayland, Mesa, GNOME-stack) стал использовать Meson, вместо CMake. Это вселяет некоторую надежду на то, что монополии CMake уже никогда не случится.

Installation and Packaging with CPack тем кому интересно рекомендую посмотреть эту лекцию. Там товарищ из nvidia ведает о возможностях cmake и cpack.

И чо там такого в этом спак? В QBS это давно из коробки есть. Пфф

А я не вижу чем говномезон лучше чем QBS.И что дальше?