Представлен (https://groups.google.com/forum/#!topic/mesonbuild/kgQLqciq8nY) релиз сборочной системы Meson 0.49 (http://mesonbuild.com/), которая используется для сборки таких проектов, как X.Org Server, Mesa, Lighttpd, systemd, GStreamer, GNOME и GTK+. Вчера о поддержке Meson объявили (https://lists.freedesktop.org/archives/wayland-devel/2018-De...) разработчики Wayland и композитного сервера Weston (поддержку autotools планируют прекратить в течение следующего года). Код Meson написан на языке Python и поставляется (https://github.com/mesonbuild/meson) под лицензией Apache 2.0.
Ключевыми целями развития Meson является обеспечение высокой скорости сборочного процесса в сочетании с удобством и простотой использования. Вместо утилиты make при сборке применяется инструментарий Ninja (https://www.opennet.me/opennews/art.shtml?num=29525). В систему встроен многоплатформенный обработчик зависимостей, позволяющий использовать Meson для сборки пакетов для дистрибутивов. Правила сборки задаются на упрощённом предметно-ориентированном языке, отличаются хорошей читаемостью и понятны пользователю (по задумке авторов разработчик должен тратить минимум времени на написание правил).
Поддерживается кросс-компиляция и сборка в Linux, macOS и Windows с использованием GCC, Clang, Visual Studio и других компиляторов. Возможна сборка проектов на различных языках программирования, включая C, C++, Fortran, Java и Rust. Поддерживается инкрементальный режим сборки, при котором пересобираются только компоненты, напрямую связанные с изменениями, внесёнными с момента прошлой сборки. Meson можно использовать для формирования повторяемых сборок, при которых запуск сборки в разных окружениях приводит к генерации полностью идентичных исполняемых файлов.
Основные новшества (https://mesonbuild.com/Release-notes-for-0-49-0.html), появившиеся в выпуске Meson 0.49:- Реализованы новые команды: "meson subprojects download" (загрузка субпроекта), "meson subprojects update" (обновление всех субпроектов) и "meson subprojects checkout" для выполнения операции checkout или создания ветки во всех Git-субпроектах.
- Добавлено новое ключевое слово "section", применимое к сборочным опциям, которое позволяет интегрированным средам разработки группировать опции по аналогии с командой "meson configure". В "section" допустимо указания следующих значений: core, backend, base, compiler, directory, user, test;
- В объект "compiler" добавлен метод get_argument_syntax для проверки поддержки компилятором расширенных опций gcc и msvc;
- Добавлена возможность передачи аргументов в функции и методы в форме словарей (ассоциативных массивов);- В циклы foreach добавлена поддержка ключевых слов break и continue;
- Добавлен оператор "/" для соединения путей (вместо join_paths('foo', 'bar') теперь можно указывать 'foo' / 'bar');
- Добавлена поддержка кросс-компиляции для чипов Renesas RX, используя компилятор CC-RX;
- Добавлена опция "b_pie" и ключевое слово "pie" для формирования исполняемых файлов в режиме PIE (position-independent executables);
- Обеспечена возможность выполнения команды "meson introspect --projectinfo " без наличия настроенного сборочного каталога;- При определении зависимости dependency('libgcrypt') в случае отсутствия pkg-config теперь выполняется поиск файлов libgcrypt-config.
URL: https://groups.google.com/forum/#!topic/mesonbuild/kgQLqciq8nY
Новость: https://www.opennet.me/opennews/art.shtml?num=49774
Как там с Meson на e2k?
пробовал на Астре Линукс Эльбрусев целом использовать вышло.. :-)
нюансы следущие:
python требуется современный (а не из репозитория говнолинуксов)
-> современный python собирается недоконца (проблемы с ffi) на Эльбрусе, но в достаточном количестве для использования Meson
Засунули с 0.46.0: https://github.com/mesonbuild/meson/pull/3115PS: но как же всё-таки эту кривулину ногами пишут...
TypeError: get_library_dirs() takes 2 positional arguments but 3 were given
(это функция и её вызов в одном и том же mesonbuild/compilers/c.py из одного и того же коммита, если что)
PPS re #48: в альте на эльбрусе сейчас питон 3.7.3, если что.
> Засунули с 0.46.0: https://github.com/mesonbuild/meson/pull/3115
> PS: но как же всё-таки эту кривулину ногами пишут...
> TypeError: get_library_dirs() takes 2 positional arguments but 3 were given
> (это функция и её вызов в одном и том же mesonbuild/compilers/c.py из
> одного и того же коммита, если что)Спасибо. А с месоном бывает весело не только на e2k.
Примеры с кроскомпиляцией есть?
примеры чего?1. примеры проектов? (которые были скомпилированы через кроскомпиляцию)
2. или примеры того как какой порядок действий делали пользователи чтобы скоспилировать кроскомпиляционно?
для случая {1} потенциально любой проект может оказаться ГОДНЫМ для кроскомпиляции. но есть вероятность присутствия ошибок в "meson.build" файле проекта, которые не позволят собрать через кроскомиляцмю.
для случая {2} -- примеры на страницах докментации
Что-то мало комментов. А такая тема многообещающая.
Священную корову C/C++ или яву - да богомерзким питоном собирать?
Таб не там поставил - весь продакшн рухнет, это же, как-никак, не скобочки!
ну и дальше по теме.
Меня, в основном, останавливает вот это:https://mesonbuild.com/Syntax.html#userdefined-functions-and...
В каких-то нетепичных случаях, боюсь, потребуется копипастить портянки кода, а затем поддерживать их в согласованном состоянии.
ай-ай-ай... это как же так. Это же блокирующая причина не использовать meson.
> Священную корову C/C++ или яву - да богомерзким питоном собирать?Это еще лайтово, один из погромистов гугля допер яву требовать для сборки _ОДНОГО_ си++ файлика.
Честно говоря, довольно старая фишка. Ныне питон у плюсов в комплекте не редкость. То разнопёстрые вспомогательные скрипты, то тесты (cxxtest, cxxmock), то сборщики (scons, waf). А вот на кой для java - не понятно. Там вроде с этим вообще своя атмосфера.
meson не нужен, есть cmake.
cmake не нужен, есть meson
cmake в отличие от этой дряни умеет генерить make-файлы.
эта дрянь умеет генерить хромоподобный асинхронный мейк-файл ninja-build
Вобще-то, у CMake есть генераторы и для ninja и даже для проектов sublime text. И в отличии от Meson, CMake может в CUDA (да, да проприетарщина, пок-пок-пок) и кучу других интересных вещей
> ... и даже для проектов sublime text. И в отличии от Meson, CMake может в CUDA (да, да проприетарщина, пок-пок-пок) и кучу других интересных вещейа нормальные (экономные и при этом linux-style) агрументы командной строки -- CMake планирует научится?
или это является якобы совсем необязательным?
ато, понимаете, компилировать под проприетарную CUDA (на компьютере с проприетарным драйвером Nvidia) -- это что-то такое что наверняка не понадобиться НИ РАЗУ в жизни нормального человека.
а вот запускать компиляцию через использование различных аргументов командной строки -- это именно то что делается довольно часто в независимости от "кучу других интересных вещей" :-) ..
улавливаете в приоритеты?
ды и сам синтаксис проектов CMake тоже не вызывает радости
> а нормальные (экономные и при этом linux-style) агрументы командной строки -- CMake планирует
> научится?уже. Это и есть linux-style.
От неосиляторов шеллов и мэйкфайлов, ага.
> ды и сам синтаксис проектов CMake тоже не вызывает радости
чо такое? Они пробелонезависимые (в отличие, кстати, от clean make), разбираться и понимать не надо - stackoverflow, ctrl-c, ctrl-v.
> разбираться и понимать не надоДля сборки hello world'ов м.б. и не надо. А в остальном синтаксис cmake не на много лучше make.
> эта дрянь умеет генерить хромоподобный асинхронный мейк-файл ninja-buildА это надо еще какую-то отдельную нинзя-дрянь ставить. Особенно угарно для прожектов на 5 файлов. Они так круто несколько микросекунд сэкономили, путем требования понаставить какой-то гадости, что я им тоже желаю гуглопрогера, который яву потребовал вкатить и прочие грэдлы для того чтобы 1 си++ файл скомпилить.
А нормальные люди смотрели на это дело, крутили пальцем у виска и жали gcc -O3 file.cpp -o program :D
> А это надо еще какую-то отдельную нинзя-дрянь ставитьМожно wget-нуть официально собранный бинарник (отсюда https://github.com/ninja-build/ninja/releases) аж 76Кб в zip. Внутри "гигантский" 183,3Кб блоб ninja. Собственно, вся установка.
>> А это надо еще какую-то отдельную нинзя-дрянь ставить
> Можно wget-нуть официально собранный бинарникА где взять для e2k или вон для riscv64 через стенку? :)
>>> А это надо еще какую-то отдельную нинзя-дрянь ставить
>> Можно wget-нуть официально собранный бинарник
> А где взять для e2k или вон для riscv64 через стенку? :)Ну, это к тому, что если он не хочет ставить, то вся ninja - это один >200Кб бинарник, который можно стащить с github для большинства случаев. Так-то оно и в репах есть (ну в Ubuntu и CentOS точно есть). Можно и собрать https://github.com/ninja-build/ninja . Смотрел бегло, но вроде на поверхностный взгляд выглядит не сильно страшно, чтобы lcc там обломался со сборкой. Впрочем, я не большой специалист по lcc, Эльбрус в руках был, пока что, от силы два рабочих дня.
> Смотрел бегло, но вроде на поверхностный взгляд выглядит не сильно страшно,
> чтобы lcc там обломался со сборкой.На всякий: packages.altlinux.org/ninja 1.9.0-alt1 собралось без пинков.
>> эта дрянь умеет генерить хромоподобный асинхронный мейк-файл ninja-build
> А это надо еще какую-то отдельную нинзя-дрянь ставить. Особенно угарно для прожектов
> на 5 файлов. Они так круто несколько микросекунд сэкономили, путем требования
> понаставить какой-то гадости, что я им тоже желаю гуглопрогера, который яву
> потребовал вкатить и прочие грэдлы для того чтобы 1 си++ файл
> скомпилить.
> А нормальные люди смотрели на это дело, крутили пальцем у виска и
> жали gcc -O3 file.cpp -o program :Dдля только лишь одного файла (file.cpp, без зависимостей) -- нет смысла использовать ни ninja ни вообще meson ни cmake..
даже bash-скрипта делать не требуется.
просто в шапке файла напиши эту строчку:
// gcc -O3 file.cpp -o programэтого должно хватить..
так что обсуждать этого НЕТ смысла в теме про meson/cmake :-)
> умеет генерить make-файлы.Не известно, для каких великих целей.
cmake был раньше. Такшта, удваиваю - Мезон не нужен.
> cmake был раньшеА Makefile был еще раньше. Следовательно, cmake не нужен. А до Makefile жили в пещерах и все было неплохо. Так что и Makefile не нужен.
оба не нужны - есть bash скрипты
Эволюция детка это когда раньше было огнива, а теперь зажигалка,
так и тут раньше был cmake, но натр@хавшись с ним придумали meson
И какие у него плюсы, собственно? Что он поддерживает полторы платформы, нифига не детектит, и вообще обкоцаный и единственным достоинством какие-то левые блабла про скорость?Так обрастет поддержкой разного добра и фичами - скорость просядет, траха прибавится и после этого найдите 10 отличий. Cmake просто уже на более поздней фазе эволюции - умеет генерить файлы для кучи билдсистем, детектит кучу всего, даже уже не сильно глюкая в этом процессе как раньше. Так что даже в нечто относительно юзабельное превратился, по сравнению с старыми версиями.
> умеет генерить файлы для кучи билдсистема зачем это было делать? :-)
действительно, нужно wget'нуть официально собранный бинарник под единственно-верный линукс, и ничего вообще не собирать, тем более что и все равно не соберется ни под чем кроме единственно-верного линукса.ваш новый стандарт, манки-кодеры.
> действительно, нужно wget'нуть официально собранный бинарник под единственно-верный линуксНу вообще-то, если внимательно посмотреть, там (https://github.com/ninja-build/ninja/releases) бинарники под linux/window/mac + тарболл.
Как минимум, на Xenial/CentOS6 (штатный gcc) и на Win7 (MSVS2015), в общем на чём я собираю и могу проверить, оно нормально работает. На Mac не пробовал (нет надобности, макбука нет, с виртуалкой извращаться лень).
похоже, они даже не догадываются, что линукс бывает не только на amd64...в принципе, незачем и париться - код, использующий это чудо вместо автоконфа, все равно там тоже не соберется, а собравшись по недоразумению - не заработает.
> похоже, они даже не догадываются, что линукс бывает не только на amd64...ну и на какой линукс тебе не хватило бинарника ninja ? (в том числе учитывая собственный репозиторий этого линукса)
LSB_VERSION="core-2.0-noarch:core-3.2-noarch:core-4.0-noarch:core-2.0-ia32:core-3.2-ia32:core-4.0-ia32"
openSUSE 11.3 (i586)
VERSION = 11.3на такой найдешь, например?
А еще ведь вообще не-интелы бывают в природе.> в том числе учитывая собственный репозиторий этого линукса
за сборочный инструментарий не-разработчики обычно берутся тогда, когда от репозитория ничего хорошего ждать не приходится, это-то уж можно было бы понять?
иначе я бы прямо из него вытащил бы "официально собранный бинарник".
правда, нафига он нужен, такой оперсорс, когда есть божественная десяточка?
The support for openSUSE 11.3 ended January 20th 2012
> The support for openSUSE 11.3 ended January 20th 2012и чо? Повторяю - там где он не "ended" я "прекомпиленный бинарник" не сборочной системы сборки сборочной системы, а того, что, собственно, мне нужно, скачаю из репозитория.
А там где мне зачем-то понадобились сборочные инструменты - оно, вероятнее всего, в принципе не собирается без правок кода.
У новых-модных-я-у-мамы-разработчиков - точно. Старые иногда умели пользоваться autoconf не для генерации интуитивно-приятного интерфейса, и не для замены своего неумения писать мэйкфайлы, а по прямому назначению - для автоматизации написания переносимого кода - в той мере, в которой это можно и нужно автоматизировать.
Ну, да, тоже не всегда - mono тому антипример.
>> The support for openSUSE 11.3 ended January 20th 2012
>
> и чо? Повторяю - там где он не "ended" я "прекомпиленный бинарник" не сборочной системы сборки
> сборочной системы, а того, что, собственно, мне нужно, скачаю из репозитория.это значит что врядли вообще можно надёжно ожидать что программа зауститься на таком хламе:
даже если тебе повезло со сборочной системой -- кроме неё существуют также и glibc разных версий/возможностей а также прикладные библиотеки
> это значит что врядли вообще можно надёжно ожидать что программа зауститься на таком хламепрограмма, авторы которой ниасилили нормальные инструменты - не запустится, уверен.
Даже если это пресловутая гуглопрограмма из единственного cpp файла.
Я и говорю - ненужно эти ваши прекомпиленные бинарники сборщика сборщика сборщика - качайте сразу из universe репозитория или вон из снапа вашей единственно-правильной убунточки сразу прекомпиленый бинарник того что вам не надо собирать, вы все равно там ничего не захотите исправлять, даже если сможете.
Оно все равно работает только в самой распоследней бывшей у автора версии и только в той позе, в которой он ее осилил собрать.
Ага, и теперь уродуются с мезоном об питон -- первое попавшееся: https://github.com/mesonbuild/meson/commit/de175aac0051b5625...Нет уж, лучше make. И если у автокрапа документация не хуже -- то, пожалуй, я бы лучше его разучил, чем эти метания об стену наблюдать.
С одной стороны> Код Meson написан на языке Python
С другой стороны
> поставляется под лицензией Apache 2.0
> таких проектов, как systemd, GStreamer, GNOME и GTK+Не могу определиться, мезон это хорошо или нет.
Это позволяет за считанные секунды описать процесс сборки в простой си подобной форме,
что конечно удобно, но вот Python как бы показывает, что проект не созрел.С другой стороны Git тоже сначала не был на Си написан.
Ничего дорастет до взрослого состояния перепишут на Си.
С одной стороны переписать на Си его можно (как и почти всё вообще), но так ли это нужно, если оно хорошо работает на питоне?
На встройках и железе двадцатилетней давности им вряд ли кто-нибудь будет собирать, а затянуть сборочной зависимостью питон и использовать на чем-нибудь помощнее себе нормально.
Разве что с кросс-компиляцией в чем-нибудь типа pdebuild могут быть проблемы, но там дебиановцы ССЗБ и не смогли в архитектуру зависимости "any" и тянут на host python:target, который пытается собой исполнить скрипт в postinstall и там и умирает.
>Это позволяет за считанные секунды описать процесс сборки в простой си подобной формев каком месте синтаксис meson с-подобный?
>> В циклы foreach добавлена поддержка ключевых слов break и continue;%%%ть! Затащить целой питон, чтобы писать правила на каком-то недоязыке.
Опять лисп изобретают.
DSL же.
> Опять лисп изобретаютНаоборот Python упрощают под нужды сборки.
> Затащить целой питон
Который и так везде (ну практически) есть.
Там от питона используют только парсилку грамматики,
так что думаю, что со временем перепишут на анси си
>Опять лисп изобретают.Кстати.
А какие альтернативы?Факт раз - тащить целый что-то придётся, современная система сборки это весьма нетривиальный продукт. CMake, autocrap, SCons, meson - всё большое само по себе, и/или тащит что-то большое зависимостями.
Факт два - язык таки нужен, и именно недоязык. Во-первых, чтобы на нём удобнее было описывать сборочную специфику, которая как минимум декларативна. Во-вторых, чтобы не дать возможность писать полноценные программы. SCons, который позволял питоновский код, показал к чему это приводит - сборка любого хелловорлда превращалась в портянку текста, который, даже не смотря на то что он был питоном, выглядел как перл.
> Факт раз - тащить целый что-то придётся, современная система сборки это весьма
> нетривиальный продукт. CMake, autocrap, SCons, meson - всё большое само по
> себе, и/или тащит что-то большое зависимостями.autocrap и сам по себе небольшой, и тащит только m4, который вообще крохотный.
и, самое главное - он нужен только и исключительно разработчику, желающему что-то поменять не в коде, а в механизме его сборки. Всем остальным (включая тех кто правит код) он не требуется - необходимо и достаточно запустить configure. Но это немодно, немолодежно, и мы его уже добавили в .gitignore, чтоб жизнь медом не казалась.
Непонятно только зачем это тащют для сборки си и крестовых проектов, собирали бы свои питоны этим.
Ещё какой то waf есть, тоже питоноподелие для сборки, mpv к сожалению этим собирается.
На сколько наблюдаю waf и scons не прижились, а вот meson вроде бы поддержало сообщество
так что есть вероятность что на определенном этапе его популярности его перепишут на си
Это потому что за ним Красная Шапка стоит!
На waf ещё и samba с какого-то бодуна успели перетащить...
Последние оода три не видел девелоперских систем без питона, даже виндовых. Всё равно что-то его притаскивает
man make
>
> man make
>make то он (g/b/n/p)make, но тот же бсдшный make и gnu make -- могут быть два довольно разных мейка.
Хотя, можно смотреть в сторону мейкфайлов suckless.org проектов -- там обычно только Incs/Libs пути править нужно, чтобы оно собиралось на не-пингвине.
К сожалению, make это построитель дерева зависимостей для роаспараллеливания "выполнения" заданий.meson это немного другого уровня инструмент, он понимает и знает какие инстурменты есть и умеет формировать в зависимости от платформы команду и ключи, а так же исследовать окружение
Хотя цель у инструментов одинаковая, но meson ближе к синструментам вроде ant и maven нежели к make
ant - чистой воды make на яве и для явы со своим синтаксисом. Независимость от shell - единственное его коренное отличие от make
meson — это замена autotools. замена make — это ninja-build
совсем распоясались. vim, gcc и вам хватит. чет народ ваще оборзел)))) ахахах скоро кодить надо будет через решение спец задач по поиску нужной кнопки в сборщике сборщика, который собирает сборщика. :)
Кто-нибуь разбирался со сборкой wxWidgets под Windows в meson.
Прочитал закрытые задачи на GitHUB по meson, но так и не понял
существует ли путь собрать проект с wxWidgets под Visual Studio.Пакет wxWidgets скачан лежит в какой-то директории.
Что-то там непонтяное вроде и пакетный менеджер vcpck советуют,
но так и не понятно уже есть поддержка или нет.Смотрел в сторону сборки clang под win32, но тоже не нашел упомнианий.
Вообще как-то глухо. Работы идут в этом направлении?
Неужеле все перебрались под .NET?
Фантомас в очках на аэроплане: собрать wxWidgets в винде шлангом и прикрутить это к дотнету, во.
> Смотрел в сторону сборки clang под win32, но тоже не нашел упомнианий.Разработчики Clang-а не выпендриваются и используют CMake. Зависимостей от сторонних библиотек нет, собирается элементарно. Упоминаний чего не нашлось?
>> Смотрел в сторону сборки clang под win32, но тоже не нашел упомнианий.
> Разработчики Clang-а не выпендриваются и используют CMake. Зависимостей от сторонних библиотек
> нет, собирается элементарно. Упоминаний чего не нашлось?Meson ещё не было когда появился clang
Верно, но в списках рассылки ("llvm-dev" и "cfe-dev") за весь этот год не нашлось ничего даже отдалённо напоминающего переход с CMake на сабж.Вопрос "Упоминаний чего не нашлось?" также остаётся открытым.
> Разработчики Clang-а не выпендриваются и используют CMake. Зависимостей от сторонних
> библиотек нет, собирается элементарно. Упоминаний чего не нашлось?эммм...
LIB_DEPENDS= libcurl.so:ftp/curl \
libexpat.so:textproc/expat2 \
libjsoncpp.so:devel/jsoncpp \
libuv.so:devel/libuv \
librhash.so:security/rhash(весь вот этот мусор, кроме разьве что expat, архи ведь важен для банальной генерилки мэйкфайлов, ага). Про кольцевые зависимости в нем, когда что-то от чего зависит, вроде, libuv, требует для своей сборки cmake, я уже когда-то писал.
а на кой вообще хрен нужена библиотека асинхронного ввода-вывода для системы сборки?в первых: можно было воспользоваться средствами которые предлагает ядро: epoll() (и select() для инвалидных операционных систем).
во вторых: CMake же вообще ничего даже НЕ собирает -- он только делает файл для ninja. ЗАЧЕМ ТУТ АСИНХРОННОСТЬ?!?!
ды и json разве там есть?
исходники cmake доступны, изучать никто не запрещал.
изучи для чего нужна та или иная зависимость, да поделись с общественностью своими открытиями.
> а на кой вообще хрен нужена библиотека асинхронного ввода-вывода для системы сборки?не знаю и знать не хочу. Я и так плохо сплю.
> в первых: можно было воспользоваться средствами которые предлагает ядро: epoll() (и select()
> для инвалидных операционных систем).вот они и воспользовались, как умели - притащив зависимость от библиотеки, не разбираться же ж самим.
> ды и json разве там есть?
как видишь.
то есть, вероятно, без него как-то соберется, но не факт что после этого соберет то, чего ради ты собирал себе cmake.
это, заметим, базовые зависимости - там еще есть такие, которые включаются отдельно по запросу.
И отдельно еще модули.autoconf, говоришь, плохой? (напоминаю, что по задумке, ни он сам, ни m4 вообще не должны присутствовать на машине, используемой для сборки или отладки проекта)
Глянь msys2. Clang там был. М.б. и wxWidgets есть, но это не точно.