Опубликован релиз сборочной системы Meson 0.52, которая используется для сборки таких проектов, как X.Org Server, Mesa, Lighttpd, systemd, GStreamer, Wayland, GNOME и GTK+. Код Meson написан на языке Python и поставляется под лицензией Apache 2.0...Подробнее: https://www.opennet.dev/opennews/art.shtml?num=51630
Когда уже можно будет сделать Deb пакет и загрузить на сервер прямо из Meson?
Сегодня можно, вроде бы никто не против.
Вот уж нет я не разрешал делать такого. Такое можно будет делать только после выхода systemd-mesond, а до этого я буду считать это нарушением лицензионного соглашения.
Ты опшшять выпшшшодишшшь на пшшшвязь?
Мейнтейнеры Debian против.
Никто не мешает иметь сопровождать свой репозиторий.
шли бы они со своим NIH-синдромом. их дебхелпер неюзабебен чуть более, чем полностью.
Так не реализовано же? Смотрим по ссылке https://mesonbuild.com/Creating-Linux-binaries.html и видим только .tar.gz можно сделать с исходниками или установить в систему и то не ясно в DIST_DIR?
У меня есть имплементация. Но я её ещё не релизнул.
Только CMake только хардкор.
Ну если хардкор, то Automake
руками, самописными shell-скриптами
готовую систему автосборки им видете ли подавайте
Если хардкор, то ручками команды, как в LFS :)
LFS на 99% состоит из команд запуска готовых сборочных систем в пакетах, вы о чём вообще?
На мезон уже достаточно говна вылили, повторяться не стану. Но вот это:> позволяющий использовать Meson для сборки пакетов для дистрибутивов
> Правила сборки задаются на упрощённом предметно-ориентированном языке- вот точно упоротые. Та же rpmbuild собирает пакет по банальному спеку. Для фигак фигак и в продакшн все уже давно есть! :) И без всяких нетрадиционно-ориентированных йазыков.
Если они сами делают спек и/или debhelper, то это много упрошает, много стандартизирует.Самому всю эту скуку расписывать скушно.
> Та же rpmbuild собирает пакет по банальному спеку.А та же dpkg-buildpackage — по банальному rules. Вот только когда надо собирать и deb, и rpm, приходится писать и то, и другое. А ещё бывают слаковские, фряшные, соляровские и прочие пакеты. Поэтому и существуют всякие обёртки, чтобы собирать пакеты разных форматов по одному определению (epm, cpack, fpm…). Да, они либо не позволяют использовать все фичи пакета, либо не дают полной абстракции от конкретного формата, но всё же иногда упрощают жизнь. Нет, не майнтейнерам дистрибутивов.
> Вот только когда надо собирать и deb, и rpmcheckinstall например.
Конечно, годилось не в 100% случаев, но зато процесс шел автоматически.> А ещё бывают слаковские, фряшные, соляровские и прочие пакеты.
И даже те, о которых ты скорее всего никогда не слышал ;) Но охватить все в рамках одной тулзы все равно не выйдет.
> checkinstall напримерОн умеет примерно ничего, к тому же его ломают частенько. И автоматизации поддаётся с трудом.
> охватить все в рамках одной тулзы все равно не выйдет
Моя очередь быть К. О.
*Все* никому и не нужны. Нужно какое-то подмножество.
Вот эту фразу в новости я как-то не совсем понял.
Там есть работа с pkg-config, возможность сделать разнообразные install-targets, возможность запускать скрипты перед/после install-targets. И есть аналог make dist, только оно берёт не всё содержимое каталога, а git HEAD. Собственно, всё.Если предполагают там аналог CPack, то его там нет. Скрипты сборки пакетов всё равно надо писать ручками.
Официальная дока
https://mesonbuild.com/Creating-releases.html
https://mesonbuild.com/Creating-Linux-binaries.html
https://mesonbuild.com/Creating-OSX-packages.html
>rpmbuild собирает пакет по банальному спеку.говнецо что rpmbuild, что debhelper.
Судя по твоему комментарию, ты даже не знаешь, что такое debhelper. (Подсказка: это даже близко не аналог rpmbuild.)
> Судя по твоему комментарию, ты даже не знаешь, что такое debhelper.
> (Подсказка: это даже близко не аналог rpmbuild.)Возможно, Вы тоже не в курсе, что такое rpmbuild -- загляните когда-нибудь в ближайший /usr/lib/rpm/ (особенно в технически развитых дистрибутивах).
Заглянул. Макроса %do_zaebis не нашёл, то есть аналога dh нет.
Да и вообще речь не об этом, а о том, что dh — всего лишь необязательная вспомогательная тулза.
>Код Meson написан на языке PythonЧем он тогда лучше/хуже Scons?
Meson более строгий и узконаправленный. Файлы scons ничем не отличаются от питона, поэтому достаточно сложно выработать общий code style чтобы не было бардака. Если что нетак поправьте.
Scons писали ещё более неграмотные...https://lists.altlinux.org/pipermail/smoke-room/2019-Septemb...
Я как разработчик ПО, в гробу видал такие системы сборки которые откуда то там берут опции компиляции.
И не царское(системы сборки) это дело думать о каких то там CFLAGS/CXXFLAGS .Так вот, если писатель скрипта сборки игнорит чего то там из инвайрмента, то это не проблема системы сборки.
Сразу видно человек-сборка на страже систем сборки.
> не царское(кодера) это дело думать о каких то там CFLAGS/CXXFLAGS .Вот так будет правильно. Флаги какой-то там конкретной реализации компилятора должны быть проблемой системы сборки.
А waf?
Прежде чем вообще употреблять такие слова, собери хотя бы разок свежую самбу кроссом.
Скунс не может в --help
Scons вообще за систему сборки нельзя считать - на самом деле это недофреймворк для написания оных, поэтому если вы его используете то то, что должно быть сборочным скриптом, становится исходником системы сборки. Поэтому во-первых они огромные и нечитаемые, во-вторых никакой стандартизации, нельзя просто взять и запустить scons - нужно сначала разобраться в каком виде он принимает флаши сборки, как находит зависимости, прокидывает ли окружение (по умолчанию не прокидывает, поэтому ccache, например сразу ломается) и т.д. и т.п. А потом всё это переписать чтобы работало так как надо.meson хоть и ненужная маргинальщина по сравнению с cmake, всё-таки претендует на то чтобы быть системой сборки, где можно декларативно указать что тебе нужно, и оно будет работать на разных системах так как должно.
>meson хоть и ненужная маргинальщинаredhat некоторые пакеты для dnf собирает мезоном
mesa тоже собирается мезоном.
Что такое Wayland и зачем его собирать?
А что такое systemd и зачем его собирать?
ненужноД не надо собирать - мейнтейнеры твоего дистра уже всё сделали за тебя :D
Wayland - протокол
Python - слишком жырная зависимость для сборочной системы.
Вот бы на Go написали. Был бы нативный статический бинарник. На любой ОС.
На Go написали qo. Но забросили, к сожалению. А выглядело весьма перспективно.
Я ему не доверяю, потому что он сам что-то скачивает.
Ничего он сам не скачивает. Только если попросишь.
Скомпилируй нативный статический бинарник на джава. Хотя можешь и питон нативно статически скомпилировать на любой ОС, разве что выкинуть либпитон отовсюду всё же не выйдет не избавившить от, собственно, питона. Джава правда только на линуксе (я не про gcj), там субсет джавы в 1000 раз более эффективный, но компилируется обычная жаба вроде бы, без хотспотов.
> Вот бы на Go написали. Был бы нативный статический бинарник. На любой ОС.Кодогенератор принесёте?
Нормальная зависимость. Собираю в одном проекте как зависимый проект ;)
Двачую. bazel покомпактнее будет.
> bazel покомпактнее будет.Этот тот, у которого жаба в зависимостях? Надеюсь, это был сарказм?
анаконда - 2 гига и час установки на hdd (а что либо другое на винду-десктоп смысла не имеет ставить, для линуксовых хостов питон несущественен - без него ни одна десктопная система не работает. CI, разумеется, другая история). jvm - 100 мегов. базель - 20 (встроенная jvm не учтена). Но базель имеет свои недостатки, даже если бы он весил 2 KiB, я бы его использовать не стал.
Вендопроблемки.
Выводить результаты конфигурирования после создания папки сборки так и не умеет?
Обычно что-то такое делаю:meson _build
meson configure _build
В исходниках у них такой бардак ... Руки прямо тянутся взять и пофиксить.
Не сдерживайтесь, ждём ваших патчей.
'rm -rf'?
Дык везде так пилют годами всякий говнокод. А потом люди страдають.
С другой стороны работает и ладно ...
Не то чтобы прям везде, но autocrap — весьма наглядный пример такого подхода.
И перейти на cmake?
А чем Мезон ваш лучше Симейка? Симейк вроде не плох, пока не понадобится скрипт вида `FindXXXX.cmake` которого нет в коробках.
Да ничем не лучше.> Симейк вроде не плох, пока не понадобится скрипт вида `FindXXXX.cmake` которого нет в коробках.
Ну так берёшь и пишешь. Это справедливо для всех систем сборки, с оговоркой, что у cmake «коробка» самая большая.
симейк очань плох. у него отвратительная документация, а работает он не интуитивно понятным образом, а для вылавливания багов в своём коде приходится модифицировать сами скрипты из поставки симейка. вкупе с отвратной системой типов "всё есть строка" это приводит к нежеланию копаться в симейковом коде. если же нужно сделать что-то нестандартное, то туши свет. в отличии от питона.
У CMake прекрасная документация, если ты не осилил — проблема в тебе. Со строками — да, не очень удобно, но, в принципе, для DSL это нормально. Если привык к шеллу, совершенно не напрягает.
Нестандатное делается не так уж и сложно, но для этого сначала таки надо избавиться от нежелания копаться в коде.
Документация может и не самая плохая, да только из версии в версии плодятся несовместимые изменения. Это ужасно, просто ужасно. Как только понадобится что-то немного отличного от стандартного, ты сразу нарываешься на проблемы. Месон может и не идеальный, но не просто так же он набирает популярность. После цмейка, он кажется таким мимимишечным. Цмейк очевидно для программистов с вендой головного мозга придумывался.
> из версии в версии плодятся несовместимые измененияИнтересно, как это я на них не натыкался? Все несовместимые изменения, с которыми лично мне довелось столкнуться, разруливаются policies. Может быть, ты просто не используешь cmake_minimum_required или бездумно увеличиваешь прописанное там значение, потому что так и не осилил документацию?
> Как только понадобится что-то немного отличного от стандартного, ты сразу нарываешься на проблемы.
Приведи пример. А то знаю я таких, которые вечно нарываются на проблемы исключительно из-за криворукости и пренебрежения чтением доки.
Ничего не менял, ничего. Выход был либо использовать версию трёхлетней давности, либо переписывать всё заново, потому что нигде в ченджлогах не было сказано, что что-то вообще должно поломаться в минорной версии. В итоге получилась миграция в трёх релизах подряд: autotools->cmake->meson (и это было очень утомительно).
Ну то есть конкретики не будет ⇒ балабол.
Кыш-кыш. Это было несколько лет назад, с тех пор я не использую цмейк и не интересуюсь его проблемами.
> Документация может и не самая плохая, да только из версии в версии
> плодятся несовместимые изменения. Это ужасно, просто ужасно.Это детсад №1.
> Месон может и не идеальный, но не просто так же он набирает популярность.
А там напоролись недавно на детсад №2 -- когда изменяется внутреннее API, но не то что в master -- в выпуск попадает коммит, который при этом переводит лишь _часть_ внутренних же клиентов на новые функции...
> Цмейк очевидно для программистов с вендой головного мозга придумывался.
find_package(PkgConfig) хватит всем.