Опубликован (https://groups.google.com/forum/#!topic/mesonbuild/5kU9ILjXWPk) релиз сборочной системы Meson 0.51 (http://mesonbuild.com/), которая используется для сборки таких проектов, как X.Org Server, Mesa, Lighttpd, systemd, GStreamer, Wayland, GNOME и GTK+. Код Meson написан на языке Python и поставляется (https://github.com/mesonbuild/meson) под лицензией Apache 2.0.Ключевой целью развития Meson является обеспечение высокой скорости сборочного процесса в сочетании с удобством и простотой использования. Вместо утилиты make при сборке по умолчанию применяется инструментарий Ninja (https://www.opennet.ru/opennews/art.shtml?num=29525), но возможно применение и других бэкендов, таких как xcode и VisualStudio. В систему встроен многоплатформенный обработчик зависимостей, позволяющий использовать Meson для сборки пакетов для дистрибутивов. Правила сборки задаются на упрощённом предметно-ориентированном языке, отличаются хорошей читаемостью и понятны пользователю (по задумке авторов разработчик должен тратить минимум времени на написание правил).
Поддерживается кросс-компиляция и сборка в Linux, macOS и Windows с использованием GCC, Clang, Visual Studio и других компиляторов. Возможна сборка проектов на различных языках программирования, включая C, C++, Fortran, Java и Rust. Поддерживается инкрементальный режим сборки, при котором пересобираются только компоненты, напрямую связанные с изменениями, внесёнными с момента прошлой сборки. Meson можно использовать для формирования повторяемых сборок, при которых запуск сборки в разных окружениях приводит к генерации полностью идентичных исполняемых файлов.Основные новшества (https://mesonbuild.com/Release-notes-for-0-51-0.html) Meson 0.51:
- Добавлена поддержка прозрачной сборки существующих проектов, в которых используются сборочные сценарии CMake. Meson теперь напрямую может собирать простые субпроекты (такие как одиночные библиотеки) с использованием модуля CMake по аналогии со штатными субпроектами (в том числе субпроекты на CMake могут размещаться в каталоге subprojects );- Для всех применяемых компиляторов включено предварительное тестирование через сборку и исполнение простейших тестовых файлов (sanity check), не ограничиваясь тестированием указанных пользователем флагов для кросс-компиляторов (отныне проверяются и родные для текущей платформы компиляторы).
- Добавлена возможность определения опций командной строки, применяемых при кросс-компиляции, с привязкой через задание префикса платформы перед опцией. Ранее опции командной строки охватывали только сборку для родной платформы и не могли указываться для кросс-компиляции. Теперь опции командной строки применяются независимо от того осуществляется нативная сборка или кросс-компиляция, гарантируя, что для нативных и кросс-сборок будет получен идентичный результат;
- Добавлена возможность указания флага "--cross-file" более одного раза в командной строке для перечисления нескольких cross-файлов;
- Добавлена поддержка компилятора ICL (Intel C/C++ Compiler) для платформы Windows (ICL.EXE и ifort);
- Добавлена начальная поддержка инструментария для CPU Xtensa (xt-xcc, xt-xc++, xt-nm);- В объект "dependency" добавлен метод "get_variable", позволяющий получить значение переменной без учёта типа текущей зависимости (например, dep.get_variable(pkg-config : 'var-name', cmake : 'COP_VAR_NAME));
- Добавлен новый аргумент параметров целевой сборки - "link_language" для явного определения языка, используемого при вызове компоновщика. Например, основная программа на Fortran, может вызывать код на C/C++, что приведёт к автоматическому выбору C/C++, в том время как нужно использовать компоновщик от Fortran;
- Изменена обработка флагов препроцессора CPPFLAGS. Если раньше Meson отдельно сохранял CPPFLAGS и специфичные для языков флаги компиляции (CFLAGS, CXXFLAGS), то теперь они обрабатываются нераздельно и перечисленные в CPPFLAGS флаги применяются как ещё один источник флагов компиляции для языков, которые их поддерживают;
- Вывод custom_target и custom_target[i] теперь может использоваться в качестве аргументов в операциях link_with и link_whole;
- В генераторах добавлена возможность задания дополнительных зависимостей при помощи опции "depends" (например, generator(program_runner, output: ['@BASENAME@.c'], depends: exe));
- В find_library добавлена опция static для охвата поиском только статически связанных библиотек;
- Для python.find_installation добавлена возможность определения наличия заданного Python-модуля для конкретной версии Python;- Добавлен новый модуль unstable-kconfig для разбора файлов kconfig;
- Добавлена новая команда "subprojects foreach", принимающая команду с аргументами и запускающая её во всех каталогах субпроектов;
URL: https://groups.google.com/forum/#!topic/mesonbuild/5kU9ILjXWPk
Новость: https://www.opennet.ru/opennews/art.shtml?num=50882
Gn — это интерпритатор неких скриптов, не знающих ничего ни о компиляторах, ни о флагах, ни о размещении либ. Вся эта информация хранится в скриптах, которые лежат внутри Хромиума. Хочешь собрать Хелло Ворлд, выкачивай исходники всего Хромиума. А потом еще и постоянно отслеживай, чтобы гугловцы ничего не ломали в этих скриптах, они то ничего не знают о твоем проекте и никому не гарантируют неизменность своих скриптов.О да, лучшая сборочная система.
> Хочешь собрать Хелло Ворлд, выкачивай исходники всего ХромиумаБред какой-то несешь. Каноничный и полный хелловорлд приводится самим же гуглом вот тут:
https://gn.googlesource.com/gn/+/master/tools/gn/example
> А потом еще и постоянно отслеживай, чтобы гугловцы ничего не ломали в этих скриптах
Как гугловцы поломают что-то в моих же скриптах? Опять-таки, в тебе говорит незнание матчасти и убежденность, будто нужны полные исходники хромиума. GN сам по себе минимален, все остальное (включая поддержку pkgconfig и тому подобное) лежит в дереве исходников хромиума. Копируй их себе в проект, удаляй всё, что тебе не надо, подправляй остальное под свои нужды, и всё -- ты независим от гугла.
А можно было бы включить наиболее востребованные скрипты в дистрибутив и поддерживать в них обратную совместимость… Хотя стоп, это же cmake получится.
Можно конечно. Я вообще разработчикам предлагал в GN засунуть не только востребованные скрипты, но и анализатор уязвимых зависимостей (как в гитхабе), автогенератор пакетов NPM, RPM, YPM, DEB, NIX, PIP, а еще аудиоплеер, чтоб программировать было веселее, подтягивание музыки по GEO-IP (для России например подтянется альбом Михаила Круга), ну и еще связку журнала "Огонек" за прошлый год.А разрабы не поняли и сказали, что это противоречит принципу "делай что-то одно, но делай это хорошо". Сказали, что оглядываются на RPM, - макросы для пихона и тому подобных штукенций разрабатываются (с точки зрения RPM) third-party-лицами -- федорой и прочими дистрами. RPM чисто предоставляет механизм (как и GN), а уж решение, как пакетировать (оформлять сборку GN) принимается на конечных местах.
# dnf provides /usr/lib/rpm/macros
rpm-4.14.2.1-4.fc30.1.x86_64 : The RPM package management system# dnf provides /usr/lib/rpm/macros.d/macros.systemd
systemd-rpm-macros-241-7.gita2eaa1c.fc30.noarch : Macros that define paths and scriptlets related to systemd
Во-первых, не надо передёргивать. Во-вторых, с rpm-макросами всё обстоит точно так же, как с модулями cmake: наиболее востребованные идут в комплекте, специфические поставляются вместе с соответствующим софтом.
Пробовал, понравилась эта система сборки, но на продакшен так и не попала ни в одном проекте, увы. Её бы переписать на Go в один бинарник, это было бы интересно...
помню, как тут все плевались с этого мезона. "Нинужно" и т.п.а сейчас ничего - все пользуются
Кто - все? Питон обязателен - значит "нeнужно". Я ещё не совсем спятил, чтобы заставлять пользователей ставить питон и зависимые либы только ради мезона.
>Питон обязателен - значит "нeнужно"Господи, ну считайте, что Python это just another ***sh. Башем-то пользуетесь, и не паритесь, что он установлен, ну вот и с Пайтоном так же кто мешает?
> ну считайте, что Python это just another ***sh.Вот только не надо про то, что это shall. В Bash я могу быть уверен (как максимум, в двух ветвях - полноценный линукс или busybox). А в питонах, где ни запустишь, ловишь дичь какую-то из-за несовместимостей версий. Язык должен быть железным как bash или Ruby. Или, сразу, бинарный код.
>или RubyВот не в курсе, что там у рубистов - у Ruby разве нет проблем с совместимостью версий? Или врут хейтеры, собаки?
> у Ruby разве нет проблем с совместимостью версийкуда больше, чем у питона, вы с сумашедшим общаетесь, если он этого не осознает
> у Ruby разве нет проблем с совместимостью версий? Или врут хейтеры, собаки?Довольно редко. Обычно раз в 5-10 лет это происходит. Да и то, по мелочам.
> В Bash я могу быть уверен (как максимум, в двух ветвях - полноценный линукс или busybox).В busybox нет bash, там ash. В минимальных установках ряда дистрибутивов тоже может не быть bash.
Удачи с обновлением скриптов на баш 5.
> В Bash я могу быть уверенАаааага. Давайте ка вы будете уверены в sh. А вот его жирненький дружочек bash таки разный от дистра к дистру. Где-то есть, где лежит не в том каком-то месте, а где-то его и нет (и это нормально).
> Башем-то пользуетесь, и не паритесь, что он установленКогда надо — паримся и пишем на POSIX shell.
> Господи, ну считайте, что Python это just another ***sh. Башем-то пользуетесь, и не паритесь, что он установлен, ну вот и с Пайтоном так же кто мешает?Да, потому что shell для административных задач -- куда более удобный инструмент. shell-скрипты меньше по объёму и как правило более-менее хорошо написаны, в то время как любой python-скрипт огромен по размеру и склонен быть глюкодромом. И по-видимому, весьма много людей так или иначе столкнулись с плохим поведением python и хорошим поведением shell.
Это, безусловно, субъективный опыт. Если хотите, мы можем поспорить на тему python vs shell, и в процессе составить табличку плюсов и минусов. Это будет хорошая замашка на объективность.
Для себя взял за правило вотэтовот >>>Bash использую до 40 строк.
Python использую от 40 строк.
Тут больше от наличия/сложности логики зависит, чем от размера. Если нужно последовательно запустить 100 программ с параметрами, баш лучше подойдет, а если какая-то математика или работа со строками, то и от 40 строк на баше удавишься
> если какая-то математика или работа со строками, то и от 40 строк на баше удавишьсяЭто ещё смотря что за работа со строками.
> Тут больше от наличия/сложности логики зависит, чем от размера.А у меня -- от необходимой сложности структур данных и наличия готовых библиотек (кстати, кто не знал, угощайтесь: http://altlinux.org/libshell).
> кто не знал, угощайтесь: башизмы с шебангом /bin/shСпасибо, обойдёмся.
> shell-скрипты меньше по объёму и как правило более-менее хорошо написаныИли ты ничего не понимаешь в шелл-скриптах, или просто не смотришь на скрипты, написанные другими. Большинство пишет их ужасно, потому что считает, что это просто, и учиться там нечему.
> Большинство пишет их ужасно, потому что считает, что это просто, и учиться там нечему.Это специфично для программирования в целом. Подставьте вместо "shell" любой другой язык -- и это тоже будет правдой.
> Питон обязателен - значит "нeнужно".Вообще, разработчики meson говорили пару раз, что чисто в теории можно и без python. Но есть два но... Сейчас система сборки еще не устаканилась и фичи постоянно добавляются, поэтому прямо сейчас отвязывать бессмысленно. Сами разработчики не заинтересованы в отвязывании от питона, но кто-нибудь другой может заняться.
А зачем отвязывать, чтобы усложнить разработку и повысить порог вхождения для контрибьюторов? cmake вон написали на крестах, получилась говнистая архитектура, в которой левая нога не знает, что правая делает, и нужно придумывать всякую дичь вроде generator expressions, чтобы это скомпенсировать
Чем вам configure && make && sudo checkinstall не угодил? Мало смузи?
> sudo checkinstallВ другую-то крайность кидаться не надо...
учитывая удивительный мирок ./debian/ и странности современного rpm (не умеющего без лишних пинков банально собрать все указанные ему файлы уже установленные куда и как надо в пакет) - checkinstall нельзя назвать плохим решением. Если бы еще и поддерживался...
Это тебе они всем угодили. А нам не угодили libtoolize && autoconf && automake. Много сивухи.
Лишних зависимостей маловато. Вот притянуть питон/руби/.NET/JRE/node.js/прочую-пoебень - наш выбор!
уж лучше в завиимостях иметь питон, чем дич вроде autoconf
Это для разработчика только. Для потребителя autoconf не создаёт никаких лишних зависимостей, и в этом его killer-фича.А вообще, сегодня 90% софта linux-only, так что там и autoconf обычно не нужен - gmake+sh вполне хватает
> Это для разработчика только. Для потребителя autoconf не создаёт никаких лишних зависимостей,
> и в этом его killer-фича.причем - даже если "потребитель" не такой уж и потребитель, и вполне способен поправить что-то в исходниках.
Пересобирать configure ему ради этого не потребуется.Но манки-кодерков уже не остановить :-(
> А вообще, сегодня 90% софта linux-only, так что там и autoconf обычно не нуженautoconf обычно нужен из-за неумения написать какой-нибудь build.sh (и можно даже обозвать его configure, как, к примеру, nginx) обрабатывающий --with-another-ненужнаяхня.
Ну не владеют обезьянки шеллом, не говоря уже про make, они только игого умеют.
> даже если "потребитель" не такой уж и потребитель, и вполне способен поправить что-то в исходниках.Даже если потребитель и не правит ничего в исходниках, а просто хочет их собрать неканоническим образом, например, со статическими либами… А там libtool… И всё, приплыли, configure падает.
у него все еще есть выбор - пропатчить достаточно простое место в сгенеренном makefile, или идти изучать дурацкий синтаксис.в случае мезона выбора нет - даже если ты всего лишь хочешь собрать бинарник - хромую хрень тебе в src.
P.S. в целом же согласен - в отличие от самого autoconf, libtool - вредная и ненужная диверсия, не решившая никогда ни одной проблемы, для которых якобы была придумана, зато очень сильно изгадившая возможность ручного вмешательства в сборку.
> пропатчить достаточно простое место в сгенеренном makefileТак он не сгенерировался, configure же упал.
> или идти изучать дурацкий синтаксис
Чем он поможет? libtool ломает логику autoconf by design, это не лечится никаким волшебным синтаксисом. Только хардкод линковки либ или их переопределение переменными окружения.
> Так он не сгенерировался, configure же упал.в смысле "упал"? Вообще не нашел библиотеку в нестандартном месте ? На самом деле - редкость (что и настолько нестандартное что сам не нашел, и руками помочь нельзя)
Тогда еще проще - патчится скрипт configure, уж это-то каждый дятел умеет, тест выкинуть, жестко забить туда правильный параметр.Чаще бывает что собирает с ней неправильно (нужен rpath, нужно правильное имя а авторы не знали зачем у .so бывает еще какое-то там .0 на конце и т д), это геморройнее чинить.
> Чем он поможет?
добавить еще одно --with-shitlib= - не такая уж сложная задача. Просто, чаще всего, ненужная - такая сборка "одноразовая".
> в смысле "упал"? Вообще не нашел библиотеку в нестандартном месте ?В смысле, он и не знал, что её надо искать. Они ищет libfoo, есть только libfoo.a. Если бы для сборки теста использовался libtool, он, конечно, заглянул бы в libfoo.la и узнал, что ей требуется ещё libbar, но тесты-то не libtool'ом собираются, а напрямую компилятором. И всё, линковка падает, либа типа нерабочая, кури, чувак, логи и исправляй это как хошь.
С so таких проблем не бывает, поэтому всем [твой ник]уй.
Так если "есть только libfoo.a", libtool тут не причем. Может собирете уже тогда libfoo.la?
Ещё раз для тугодумов: libfoo.la тоже есть, но тест линковки (стандартный автоконфовский) не использует libtool, поэтому толку от него ноль с точкой вместо палки.
А можно подробнее, как именно configure падает? Сам libtool не нужен для дистрибутива с исходным кодом.
> А можно подробнее, как именно configure падает?См. #52.
> Сам libtool не нужен для дистрибутива с исходным кодом.
Да что ты говоришь? А если посмотреть повнимательнее и обнаружить волшебный скриптик ./libtool, который любезно подложил libtoolize?
> скриптик ./libtool, который любезно подложил libtoolize?Хотя нет, гоню. Это было бы слишком просто для автодряни. Скриптик ./libtool, который генерит ./configure, используя ./ltmain.sh, который подложил libtoolize.
И опа! Для сборки из исходного кода, уже не нужен весь пакет libtool, а только sh. По-моему, все работает точно накже как и остальные утилиты autoconf/automake, а не "libtool ломает логику autoconf by design".
> И опа! Для сборки из исходного кода, уже не нужен весь пакет
> libtool, а только sh. По-моему, все работает точно накже как и
> остальные утилиты autoconf/automake, а не "libtool ломает логику autoconf by design".Ты читал, что я выше писал-то?
Не в том смысле ломает, что не следует политике напихивания 100500 скриптов в дерево исходников и генерации такого же их числа во время конфигурации, а в том, что тесты ./configure перестают работать так, как задумано.
#>> чем дич вроде autoconf
> Это для разработчика только. Для потребителя autoconf не создаёт никаких лишних зависимостей,
> и в этом его killer-фича.Тише, тише!
Это же Разработчик. Да, он не умеет в автоконф, либтул, баш, си, сед, авк, ... всё вот это вот.
Такие нонеча разработчики. Субж во все поля...
Ретроград! Прогресс не остановишь!
> Ретроград! Прогресс не остановишь!Ну, что вы! Кто я такой, чтобы Ваш "прогресс" останавливать.
Вы и сами отлично справляетесь.
CMake, електрон, мейзон -- выкидывайте и переписывайте уже.
К нашим-то, к ретроградам, не примазывайтексь.
Дальнейших успешных сингулярностей Вам.
1. Пока не придется разбирать эти портянки, которые трассируются очень плохо. За Meson не скажу, но с CMake проблемы решаются намного проще.
2. Язык оболочки ламповый, родной, но для чего-то кроме однострочников в интерактивном и эквивалентных им коротких скриптов он катастрофически ужасен.
3. make штука не самая быстрая
4. Checkinstall мертв, к сожалению. Но и когда был жив, часто проблем добавлял прилично (во всяком случае на не самых мейнстримных архитектурах)
> Если раньше Meson отдельно сохранял CPPFLAGS и специфичные для языков флаги компиляции (CFLAGS, CXXFLAGS), то теперь они обрабатываются нераздельно и перечисленные в CPPFLAGS флаги применяются как ещё один источник флагов компиляции для языков, которые их поддерживаютСомнительно, ИМХО может чтонить сломать
Что и как это может сломать? Я так понял, изменилось только то, как флаги хранятся в кеше, а компилятор в конечном итоге получит все те же самые.
У меня CFLAGS и CPPFLAGS обычно разные, будет плохо если они смешаются в кучу.
> У меня CFLAGS и CPPFLAGS обычно разные, будет плохо если они смешаются в кучу.Они всегда разные. И передаются компилятору именно что одной кучей. Как их при этом хранить — по отдельности или в месте — значения не имеет.
Дай угадаю: ты просто не знаешь, что такое CPPFLAGS?
>systemd, GStreamer, Wayland, GNOME и GTK+.Не нужно.
А уметь правильно писать Makefile похоже слабо юным хипстерам.
"это ж мне что - все исходники ВРУЧНУЮ перечислять в зависимостях?"
Не-не-не, вот прокатывающийся по ним скрипт, подбирающий весь мусор (включая пяток файлов, давно неиспользуемых) - это по нашему!
> "это ж мне что - все исходники ВРУЧНУЮ перечислять в зависимостях?"И ты, я гляжу, не осилил?
https://www.gnu.org/software/make/manual/make.html#Automatic...
этот трэш - и осиливать незачем. Он gmake only да еще и нужна достаточно модная версия, в старых поломано кое-что.make dep - там осиливать нечего (бонусом - что он обычно тоже нужен только один раз, при внесении изменений в дерево проекта, а не мелком патчинге) но список .c | .cxx от которых зависит итоговый бинарь он все же за тебя не соберет.
А этих .cxx в крупном проекте может быть с миллиончик.
> этот трэш - и осиливать незачем. Он gmake only да еще и нужна достаточно модная версия, в старых поломано кое-что.И что же там gmake only? Шаблонные правила, разве что? Замени их суффиксными. Что ещё?
> но список .c | .cxx от которых зависит итоговый бинарь он все же за тебя не соберет.
А кто соберёт-то? automake не соберёт, cmake не соберёт, насчёт сабжа тоже сильно сомневаюсь.
Давно было, написал универсальный makefile со всеми зависимостями, сам все находит строит зависимости, собирает. Не зависит ни от каких доп скриптов. Вообще делать с ним ничего не надо. Работает на любой системе, пихаю его везде. Таких лисапетов в инете давно полно. Нет, надо изобрести корявого глючного монстра.
Увы, такое реально только для hello world'ов. А если в проекте несколько библиотек и несколько бинарей, и у всего свои внешние зависимости, придётся таки чуть-чуть поднапрячься.
есть и список внешних либ и свои промежуточные и цели сколько надо, достаточно просто. А проекты далеко не самые простые.