LINUX.ORG.RU

Meson 1.11.0

 


0

3

Проект Meson выпустил версию 1.11.0. Релиз состоялся 13 апреля 2026 года и продолжает развитие одной из самых заметных свободных систем сборки, используемой во множестве Linux и кроссплатформенных проектов.

Meson традиционно делает ставку на высокую скорость, предсказуемое описание сборки и сравнительно простой DSL, а новый выпуск в основном сосредоточен на практических улучшениях для реальных сценариев разработки.

Ключевые изменения в Meson 1.11.0:

  • поддержка разбора верхнеуровневого Cargo.toml через workspace() в Rust-модуле;
  • поддержка link_args, add_project_link_arguments() и add_global_link_arguments() для Rust;
  • новый метод compiler_target() в Rust-модуле;
  • Cython больше не требует явного включения C или C++;
  • новый аргумент link_early_args для более ранней передачи опций линковщику;
  • meson dist получил поддержку -j/--num-processes;
  • install_man и install_headers теперь поддерживают install_tag;
  • дедупликация OpenMP linker arguments;
  • автоматическое определение QT_DEBUG и QT_NO_DEBUG;
  • улучшения для Windows-окружений и rc.exe.

Одно из самых заметных изменений касается Rust. Meson 1.11.0 научился разбирать верхнеуровневый Cargo.toml при вызове workspace() в Rust-модуле, благодаря чему зависимости и feature-флаги теперь разрешаются в соответствии с конфигурацией рабочего пространства Cargo. Это делает интеграцию с Rust-проектами заметно более зрелой: возвращаемый объект workspace позволяет получать сведения о зависимостях и features для Cargo-субпроектов, а также собирать цели, описанные в Cargo.toml.

Разработчики также расширили работу Meson с Rust на этапе линковки. Начиная с версии 1.11.0, для Rust поддерживаются add_project_link_arguments(), add_global_link_arguments() и link_args, которые передаются через rustc с обёрткой -Clink-arg=. Кроме того, в Rust-модуле появился метод compiler_target(), возвращающий target triple компилятора, что упрощает перенос сценариев, ранее завязанных на переменные Cargo вроде TARGET и HOST.

Ещё одно прикладное изменение затрагивает Cython: теперь для работы с ним больше не требуется явно включать языки C или C++. При этом Meson оговаривает, что такие языки добавляются только как внутренняя деталь реализации Cython, а не как полноценная возможность параллельно собирать обычные native C/C++ targets. Для пользователей это, прежде всего, упрощение конфигурации сборки.

В релиз вошли и улучшения, рассчитанные на более тонкий контроль линковки и установки. У целей, выполняющих линковку, появился новый аргумент link_early_args, позволяющий передавать опции линковщику до объектов и библиотек — это важно для параметров вроде -u или --defsym, которые чувствительны к порядку. Также install_man и install_headers получили поддержку install_tag, чтобы установленными файлами можно было гибче управлять через meson install --tags.

Отдельно стоит отметить развитие инструментов сопровождения сборки. Команда meson dist теперь принимает -j и --num-processes, что позволяет управлять числом параллельных процессов при проверке дистрибутива. Параллельно Meson начал дедуплицировать линкерные аргументы OpenMP, такие как -fopenmp и -qopenmp, а в Qt-модулях теперь автоматически определяются макросы QT_DEBUG или QT_NO_DEBUG в зависимости от режима сборки, что приближает поведение к qmake.

Изменения есть и в совместимости со специфическими платформенными сценариями. В модуле external_project для Windows теперь используется cygpath, чтобы корректно преобразовывать пути к Unix-виду при работе с configure-скриптами в окружениях вроде MSYS2 и Cygwin. Кроме того, windows.compile_resources теперь умеет отслеживать изменения заголовков при использовании rc.exe, обходя давнее ограничение этого компилятора ресурсов.

В целом Meson 1.11.0 выглядит как релиз без громких революций, но с заметным количеством инженерно значимых доработок. Главный смысл выпуска — сделать систему сборки удобнее для современных mixed-language-проектов, особенно там, где рядом живут Rust, Cython, Qt и традиционные C/C++-компоненты. Для разработчиков это, скорее, не повод переписывать инфраструктуру, а аккуратное, но полезное обновление инструмента, который и так давно стал частью повседневного стека свободного ПО.

>>> Источник

★★★★★

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

А что там слышно про muon (который совместим с meson, но отвязан от питона)? По фичам сильно отстаёт?

hobbit ★★★★★
()

Meson традиционно делает ставку на высокую скорость, предсказуемое описание сборки и сравнительно простой DSL, а новый выпуск в основном сосредоточен на практических улучшениях для реальных сценариев разработки.

Звучит как описание любой системы сборки от разработчиков этой системы сборки.

Camel ★★★★★
()

В целом Meson 1.11.0 выглядит как релиз без громких революций

модераторы, купите мальчику доступ до нормальных ИИ моделей

gagarin0
()

Я как-то пытался с ним мириться, но пока забил из-за того что там нельзя нормально сделать многоуровневое подключение проектов.

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

модераторы, купите мальчикy

А чО сразу модераторы??.. Вот сам и покупай!.. А у модераторов наверняка есть свои мальчики, которым модераторы игрушки и покупают. Зачем им чужие мальчики??..

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

А чО сразу модераторы??

потому что они подтверждают громкие революции

gagarin0
()
Ответ на: комментарий от wandrien

Помню что в Мезоне гвоздями прибита схема при которой файлу одного языка соответствует один компилятор.

Например, если нужно те же .h заголовки распарсить чем-то, кроме компилятора C, то уже приходится танцевать в гамаке на лыжах

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

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

Ja-Ja-Hey-Ho ★★★★★
()
Ответ на: комментарий от ulyssesjj

meson - жалкий клон автоклунза с большинством его детских проблем. Постоянные неполные, либо избыточные пересборки, завязывание build tree на абсолютные пути, требование питухона... Даже cmake лучше справляется со своей задачей

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

В мире C++ cmake — стандарт де факто. Он же и самый удобный ибо дефолт и есть во всех проектах

Он не самый удобный. Он единственный кто может в генерацию проектов вижуал-студии.

sarumeister
()

Главный смысл выпуска — сделать систему сборки удобнее для современных mixed-language-проектов, особенно там, где рядом живут Rust, Cython, Qt и традиционные C/C++-компоненты.

В чём неудобство прописать вызов компилятора для исходных текстов программы в обычных мэйкфайлах? Среды разработки, например, «Нетбинс» сами создают мэйкфайлы и самому даже думать об этом не требуется. Зачем нужно это переусложнённое нагромождение кода сборки исходников?

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

Тогда проще создать мелкий шел-скрипт, чем инкостылировать мейк.

Так мэйкфайлы в наши дни создавать вручную тоже уже требуется, если использовать современные среды разработки. Если среда разработки создаёт «чистый» мэйкфайл, то в чём смысл от «мезоновских» прослоек?

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

Зачем что чистый makefile слишком многословный и еще с генерацией зависимостей надо приседать. И да держать в проекте сгенерированные какой-то средой разработки makefile это дурной тон.

Reset ★★★★★
()

Грустно конечно, что gnu make имеет настолько запутанный синтаксис и мало возможностей, что приходится использовать сторонние инструменты сборки, но сркди сторонних инструментов meson самый удобный.

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

Что там запутанного? target: deps —>command ??

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

ulyssesjj
()
Ответ на: комментарий от Enthusiast

Я имею ввиду тупой шел-скрипт вида

COMMAND="${1:-help}" ; shift
DEST="${1:-"/usr/local"}" ; shift
case "$COMMAND" in
    i|install)
        "${SUDO:-sudo}" cp build/app "${DEST}/bin/app"
;;  u|uninstall)
        "${SUDO:-sudo}" rm -f "${DEST}/bin/app"
;;  b|build)
        mkdir -p build
        gcc "${SOMEFLAGS[@]}" src/app.c -o build/src # Тут должно быть что-то посложнее
;;  -h|--help|h|help)
        printf "usage: $0 [ install [ <path> ] | uninstall [ <path> ] | build | help ]"
;;  esac

который может иногда заменить мейкфайл, исключая make из зависимостей в проекте

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

Я имею ввиду тупой шел-скрипт вида

А где здесь комбинаторный взрыв? В правильных билд-системах а) есть комбинаторный взрыв, б) комбинаторный взрыв успешно разруливается.

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

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

Тут (github.com) я сделал специальный что−то—типа пакетный менеджер чтобы собирать свежый elinks в аппимадж с финтефлюшками и без прав root. Где-то компромиссное, но тем не менее, рабочее решение на bash, с этим самым взрывом

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

Оно никаким не должно быть. Скрипт-установщик должен пользоваться теми правами, что ему выдали, а не устраивать самодеятельность. Там, может быть, префикс в $HOME или в /tmp например - всё на усмотрение запускающего.

А если даже префикс в /usr но скрипт запущен не от рута - надо упасть с ошибкой недостатка прав. Представь, что программа cp бы предлагала ввести рут-пароль когда не может создать файл назначения - это ж бред. Установщик тут ничем не особенный.

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

я сделал специальный что−то—типа пакетный менеджер чтобы собирать свежый elinks

Куда смотреть? Я вижу вызов Meson с флагами.

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

Грубо говоря, meson не make. ninja - да. pkgup это 3-make, meson или autotools − 2-make, ninja или make − 1-make. pkgup обеспечивает скорее не комбинаторный взрыв, а вывих моска, так как вместо упоротого DSL тут bash, что хоть и не сахор, но и не мейк.

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

meson не make. ninja - да. pkgup это 3-make, meson или autotools − 2-make

Вот тебе autotools и генерят баш-портянку на 80К нечеловеческого кода, чтобы поддержать комбинацию флагов типа:

  --enable-256-colors \
  --enable-fastmem \
  --enable-utf-8 \
  --with-static \
  --with-openssl \
  --without-gpm \
  --without-quickjs \
  --disable-88-colors \
  --disable-backtrace \
  --disable-bittorrent \
  --disable-debug \
  --disable-cgi \
  --disable-combining \
  --disable-gopher \
  --disable-nls \
  --disable-ipv6 \
  --disable-sm-scripting \
  --disable-true-color \
  --without-bzlib \
  --without-brotli \
  --without-gnutls \
  --without-libev \
  --without-libevent \
  --without-lzma \
  --without-perl \
  --without-python \
  --without-ruby \
  --without-terminfo \
  --without-zlib \
  --without-zstd \
  --without-x
sarumeister
()
Ответ на: комментарий от firkax

Какое ещё sudo? Плохой скрипт.

Ну там автор скрипта честно признался: «тупой шел-скрипт».

Правда тупой тут не только скрипт.

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

А что там слышно про muon (который совместим с meson, но отвязан от питона)? По фичам сильно отстаёт?

Периодически собираю, и сравнительно недавно он смог собирать себя с такими опциями:

muon setup -D meson-docs=disabled -D meson-tests=disabled -D samurai=enabled -D readline=bestline -D libpkgconf=enabled -D libarchive=enabled buildrel

Раньше с ними только meson мог собирать.

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

cmake… Он же и самый удобный

Вот это жирнота…

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

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

Поэтому системы сборки, такие как cmake или qmake, обычно генерируют мейкфайл в качестве промежуточного представления, но не завязывают на него весь проект. А qbs, например, вообще обходится без мейкфайла.

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

Раньше с ними только meson мог собирать.

Попробовал собрать util-linux, не смог. $ muon setup buildrel

configuring '/home/data1/Repos/Git/C/util-linux/buildrel/libblkid/blkid.h'
c compiler: supports argument '-Wl,--version-script=/home/data1/Repos/Git/C/util-linux/libblkid/src/libblkid.sym': YES
configuring '/home/data1/Repos/Git/C/util-linux/buildrel/libmount/libmount.h'
/home/data1/Repos/Git/C/util-linux/libmount/python/meson.build:31:30: error unimplemented
 31 |   dependencies : [mount_dep, python.dependency(embed: true)],
                                   ^_____________________________
/home/data1/Repos/Git/C/util-linux/libmount/python/meson.build:31:30: error in function 'dependency'
 31 |   dependencies : [mount_dep, python.dependency(embed: true)],
                                   ^_____________________________
/home/data1/Repos/Git/C/util-linux/libmount/meson.build:164:1: error in function 'subdir'
164 | subdir('python')
      ^_______________
/home/data1/Repos/Git/C/util-linux/meson.build:1037:1: error in function 'subdir'
1037 | subdir('libmount')
       ^_________________
dataman ★★★★★
()
Ответ на: комментарий от dataman

Всё, что завязано на питон в meson, по очевидным причинам не работает. Так что muon вряд ли когда-то будет полноценной заменой.

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

Так что muon вряд ли когда-то будет полноценной заменой.

А если осилят свой интерпретатор python? :)


Не успел отредактировать. :)

Для git нормально генерируется build.ninja, но $ muon samu с этим файлом не справляется, в отличие от ninja.

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

А если осилят свой интерпретатор python? :)

ненужно

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

И эту баш-портянку нельзя красиво оформить, без кодогенерации autotools?
К примеру, современный баш может обрабатывать массивы:

ARGS=(
  --enable-256-colors
  --enable-fastmem
  --enable-utf-8
  --with-static
  --with-openssl
  --without-gpm
  --without-quickjs
  --disable-88-colors
  --disable-backtrace
  --disable-bittorrent
  --disable-debug
  --disable-cgi
  --disable-combining
  --disable-gopher
  --disable-nls
  --disable-ipv6
  --disable-sm-scripting
  --disable-true-color
  --without-bzlib
  --without-brotli
  --without-gnutls
  --without-libev
  --without-libevent
  --without-lzma
  --without-perl
  --without-python
  --without-ruby
  --without-terminfo
  --without-zlib
  --without-zstd
  --without-x
)

… "${ARGS[@]}"

Или можно подтянуть конфиг из файла:

… $(< args.ini)

autotools в это уиеет?

tnray
()
Ответ на: комментарий от ulyssesjj

самый удобный

Поэтому в проектах на Nim чаще используют Make, чем весь вот этот анонизм. Это ещё не говоря о сообцествах Python3, Rust, Zig, Haskell и подобных, у которых свои, более продуманые системы сборки. Взять тот же Haskell с его Cabal/Stack и Hackage, который нельзя будет перенести на рельсы Autotools/Meson. С CMake ситуация сложнее, так как он по сути такой же Cargo для C++, но более запаренный.

tnray
()
Ответ на: комментарий от hobbit

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

Да, включаем мэйкфайл в дерево исходных кодов проекта. В мэйкфайле будет однозначно видно какие именно файлы мы собираем и подключаем в зависимостях, а также с какими ключами компилятора. Для сервера мэйкфайл можно и руками написать один раз, а затем только добавлять туда вновь вносимые файлы для сборки. Что тут сложного-то?

Сила мэйкфайлов заключена в однозначном воспроизведении сборки исходных кодов проекта независимо от установленного программного окружения на сборочной ЭВМ. Скопировали исходники вкупе с мэйкфайлом и пересобрали. Просто и сверхнадёжно.

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

современный баш может обрабатывать массивы:

autotools в это уиеет?

Попробуй переписать на баш, разрешаю. (Скрипт 80К в моем комментарии это не про килобайты, это про число строк)

sarumeister
()
Для того чтобы оставить комментарий войдите или зарегистрируйтесь.