Состоялся (https://github.com/mesonbuild/meson/releases) релиз сборочной системы Meson 0.42 (http://mesonbuild.com/), использующей вместо утилиты make инструментарий Ninja (https://www.opennet.me/opennews/art.shtml?num=29525). Ключевыми целями развития Meson является обеспечение высокой производительности в сочетании с удобством и простотой использования. Создатели Meson придерживаются принципа, что каждый момент, который разработчики тратят на написание правил сборки или отладку тратятся впустую и лишь оттягивают время до того, как можно будет начать процесс сборки. Код проекта написан на языке Python и поставляется (https://github.com/mesonbuild/meson) под лицензией Apache 2.0.Основные особенности Meson:
- Многоплатформенность, поддерживается сборка в Linux, macOS и Windows с использованием GCC, Clang, Visual Studio и других компиляторов;
- Поддержка сборки проектов на различных языках программирования, включая C, C++, Fortran, Java и Rust;- Поддержка кросс-компиляции для различных операционных систем и для запуска на голом оборудовании (bare metal);
- Оптимизации для максимального ускорения процесса сборки, поддержка инкрементальных сборок;
- Встроенный многоплатформенный обработчик зависимостей, работающий совместно с пакетами в дистрибутивах (Meson можно использовать для сборки пакетов в дистрибутивах);
- Поддержка повторяемых сборок, при которых запуск сборки разных окружениях приводит к идентичному результату;- Предельно читаемые и дружественные пользователю правила сборки, задаваемые на предметно-ориентированном языке. Например, простейший файл сборки (meson.build) будет выглядеть как:
project('tutorial', 'c')
executable('demo', 'main.c')или более сложный вариант с зависимостью от gtk+-3.0:
project('tutorial', 'c')
gtkdep = dependency('gtk+-3.0')
executable('demo', 'main.c', dependencies : gtkdep)
После выполнения "meson builddir" будет сгенерирован сценарий для утилиты ninja.Сборочная система Meson c большим интересом была воспринята некоторыми крупными открытыми проектами. Например, проект systemd интегрировал (https://www.opennet.me/opennews/art.shtml?num=46843) поддержку Meson, которая в одном из следующих выпусков полностью вытеснит сборку на основе Automake. Миграцию на Meson также планирует (https://blogs.gnome.org/mclasen/2017/04/20/meson-considerations/) проект GNOME - выпуске 3.26 некоторые модули уже будут переведены на Meson. Поддержка Meson добавлена в jhbuild, GNOME builder и flatpak-builder, а сам Meson вошёл в состав GNOME SDK.
Более того, вчера объявлено (https://mail.gnome.org/archives/gtk-devel-list/2017-August/m...) о переводе master-ветки GTK+ на сборку с использованием Meson, а сборочные файлы для Autotools удалены. По сравнению с Autotools время сборки GTK+ сократилось в три раза. На пути перехода на Meson также находится (https://lists.freedesktop.org/archives/mesa-dev/2017-March/1...) проект Mesa - сборка Mesa при помощи Meson оказалась в 4 раза быстрее при первом запуске и в 10 раз быстрее при повторном.
Среди новшеств (http://mesonbuild.com/Release-notes-for-0-42-0.html), появившихся в выпуске Meson 0.42:
- Возможность создания архивов со сборками на основе кода в репозитории Mercurial;- Поддержка верификации аргументов при вызове любой функции с выводом предупреждения, если аргумент ключевого слова неизвестен;
- Поддержка компилятора для преобразования кода Genie (https://wiki.gnome.org/Projects/Genie) на язык Vala;
- Поддержка Pkgconfig для обработки дополнительных cflags
- Возможность определения настроек исполняемых контейнеров (crate) для компилятора языка Rust
- Поддержка одновременного использования детектора проблем при работе с памятью (AddressSanitizer) и детектора неопределённого поведения
(Undefined Behavior Sanitizer) через указание опции "-Db_sanitize=address,undefined";- Экспериментальная поддержка модуля для сборки кода с различными вариантами применения инструкций SIMD (модуль выбирает лучший вариант);
- Поддержка импорта библиотек для исполняемых файлов на платформе Windows;
- Добавлен модуль контроля зависимостей для графического API Vulkan- Возможность ограничения максимального числа одновременно запускаемых процессов компоновщиков
- Поддержка MPI в качестве зависимости
- Поддержка выборочного исключения файлов или каталогов из команды install_subdir;
- Доступность всей функциональности Meson через один исполняемый файл (ранее предлагались дополнительные утилиты mesonintrospect, mesonconf и mesontest которые теперь можно вызвать через команды подобные "meson configure" и "meson test".
URL: https://github.com/mesonbuild/meson/releases
Новость: http://www.opennet.me/opennews/art.shtml?num=47031
Хипсторы ниосилили make?
> Хипсторы ниосилили make?Скорее `./configure &&`make && make DESTDIR="/I/Wanted/Install/Here" install` слишком "жирный" подход.
> Скорее `./configure &&`make && make DESTDIR="/I/Wanted/Install/Here" install`
> слишком "жирный" подход.Ну если запускать всё, что эти два make выведут -- "то я за себя не отвечаю" (ц) Незнайка. Зачем Вы вписали эти две обратные кавычки?
Скорее cmake
> Скорее cmakemeson и cmake -- это системы для одной и той же целевой ниши.
самые прямые конкуренты.
оба ориентированы на C/C++ (в основном.. а всё остальное собирают плохо).
оба собирают через ninja.
оба выдумыли свой не-тьюрингполный язык описания структур. (даже учитывая что meson написан на Python и они могли бы интерпретировать Python в качестве DSL, но не стали)
выигрыш meson перед cmake в основном оказался в том что в cmake идиотские и совершенно неадекватные ключи командной строки.
ещё можно добавить что meson более дружественна к pkg-config -- а значит и более дружественна к экосистеме программ GNU/Linux
>ninjaЭто тот самый, где "для сборки ninja нужен ninja, возьмите бинарик с нашего сайта"? Пусть сами таким пользуются.
Там есть bootstrap.py
> Это тот самый, где "для сборки ninja нужен ninja, возьмите бинарик с нашего сайта"? Пусть сами таким пользуются.адепты раста и явки недоумевают.
"для сборки rust нужен rust, возьмите бинарник с нашего сайта".
"для сборки jdk нужен jdk, возьмите бинарник с нашего сайта".
Загрузка ...
моя довольна - для сборки clang C нужен C++ компилятор ;-)
> моя довольна - для сборки clang C нужен C++ компилятор ;-)Тут важно, что 1. подойдёт ЛЮБОЙ С++ компилятор (так что можно использовать тот, к которому есть доверие), 2. C++ компилятор есть практически везде (так что не надо ставить строго определённую версию ОС и софта, а можно воспользоваться уже установленной), 3. C++ компиляторов существует больше одной реализации (так что если одна из них помрёт, clang всё равно можно будет собрать).
В случае с растом и явой эти три пункта неприменимы.
> Тут важно, что 1. подойдёт ЛЮБОЙ С++ компиляторну, не то чтоб совсем любой, кажется, нужен "любой 11й", что сильно сужает выбор.
С явой и растом в этих рамках все, в общем, то же самое (ну, с явой там есть ньюансы, но мелкие, а главный - что даже воскресив gcj/icedtea/кто там еще в склепе, хрен ты ими соберешь нынешнюю яву в принципе) - раст возможно и соберется другим растом, только, вот... опаньки, нету другого. И, полагаю, никогда и не будет (как и не будет другого Go. D может и будет, хотя тоже верится с трудом).
>> Тут важно, что 1. подойдёт ЛЮБОЙ С++ компилятор
> ну, не то чтоб совсем любой, кажется, нужен "любой 11й", что сильно
> сужает выбор.
> С явой и растом в этих рамках все, в общем, то же
> самое (ну, с явой там есть ньюансы, но мелкие, а главный
> - что даже воскресив gcj/icedtea/кто там еще в склепе, хрен ты
> ими соберешь нынешнюю яву в принципе) - раст возможно и соберется
> другим растом, только, вот... опаньки, нету другого. И, полагаю, никогда и
> не будет (как и не будет другого Go. D может и
> будет, хотя тоже верится с трудом).Олдансы передают привет ньюансам.
> с явой там есть ньюансы [...] хрен ты ими соберешь нынешнюю яву в принципе
> раст [...] опаньки, нету другого. И, полагаю, никогда и не будетЯ это и имел ввиду. И как вариант, Мозилла, поигравшись с растом и переписав на нём значительную часть файрфокса, в итоге выкинет обоих и будет, как и все, делать открытую шкурку к хрому.
> как и не будет другого Go
Вроже же уже два их: гугловский референсный, и gccgo?
Го и Хаскель туда же
Разве gcc-go не сишным компилятором собирается?
Ты в курсе, что для сборки gnu make нужен gnu make? В мире тулчейнов -- это нормальная ситуация.
> Ты в курсе, что для сборки gnu make нужен gnu make?не, не нужен - bsd make собирается.
Trusting Trust — cтарая проблема.
> оба собирают через ninja.cmake работает с разными бекендами, в том числе с make от рождения.
> в cmake идиотские и совершенно неадекватные ключи командной строки
Попытался вспомнить, когда мне приходилось использовать хоть один ключ кроме -D, и не смог. Нет, когда-то точно использовал -L, но уже не помню, когда.
> meson более дружественна к pkg-config
cmake тоже прекрасно умеет работать с pkg-config, правда разработчики cmake его почему-то не любят и используют крайне редко.
>> в cmake идиотские и совершенно неадекватные ключи командной строки
> Попытался вспомнить, когда мне приходилось использовать хоть один ключ кроме -DФишка в том, что в cmake практически все настраивается через ключ -D, включая все опции определенные внутри проекта
Пользуюсь CMAKE, удобно конечно. Но бывают весьма нетривиальные вещи, иногда проще было бы описать руками процесс сборки.
В частности, некоторые пакеты, подключаются не через стандартные
if(PostgreSQL_FOUND)
include_directories(${PostgreSQL_INCLUDE_DIRS})
link_directories(${PostgreSQL_LIBRARIES})
endif(PostgreSQL_FOUND)
А вот таким способом... :(
find_package(PkgConfig REQUIRED)
pkg_check_modules(GLIB REQUIRED glib-2.0>=2.40)
pkg_check_modules(GTOP REQUIRED libgtop-2.0>=2.28)
include_directories(${GLIB_INCLUDE_DIRS})
include_directories(${GTOP_INCLUDE_DIRS})
> Пользуюсь CMAKE, удобно конечно. Но бывают весьма нетривиальные вещи, иногда проще было
> бы описать руками процесс сборки.руки отвалятся, все так описывать.
> В частности, некоторые пакеты, подключаются не через стандартные
> if(PostgreSQL_FOUND)здесь у тебя - if. то есть нашли - хорошо, подцепим, не нашли - хрен с ним. Причем все равно, какой, предполагая, что "должен остаться только один"
> А вот таким способом... :(
а вот тут у тебя - REQUIRED, причем определенных версий - то есть с другой мы работать не умеем, а без - вообще не имеем смысла.
И разруливает это не cmake, а pkg_config (который, в идеальном сферическом вакууме, может даже разрулить наличие _одновременно_ в одной системе пяти версий каждого, и выдать тебе правильный набор ключиков, чтобы ты подцепил библиотеки от правильной версии include. Правда, как правило, не работает. При сборке bsd'шных портов я обычно безболезненно выкидываю зависимости от него - все равно не нужен. configure,порожденная автоконфом, умеет в случае его отсутствия фаллбэк на обычный способ поиска)
Это разработчики systemd, GTK+ и GNOME хипсторы?
А кто они?
Только хипстеры умеют так ломать программы, чтобы обратной совместимости вообще никакой не было.
Они сделали свою обратную совместимость со смузями и покемонами!
> Они сделали свою обратную совместимость со смузями и покемонами!последняя версия без спиннера не собирается
на какой конечности нужно крутить спинер?
у покемонов спинер налезет только под квадратики
*cmake
Именно.Что характерно, все эти "предельно читаемые и дружественные пользователю правила сборки, задаваемые на неусложнённом предметно-ориентированном языке" на практике выливаются в то, что для бутстрапа таких поделий оказывается нужен ещё один язык с гораздо более развесистыми, чем make, сборочными зависимостями, а время приходится гробить всего лишь чуточку иным способом -- например, на выявление детских багов подобных "инноваций" (привет, scons!).
И об этом кричит уже одно количество таких поделий.
Ну а gnu make manual читается достаточно легко. :)
> Ну а gnu make manual читается достаточно легко.Понимаешь… есть такие, гм, кодеры, которые читают мануалы, а в оставшееся время говорят об этом. А есть такие, которые время тратят на проектирование и написание полезных штук.
inb4 покормил
Не почитав мануала? Ню-ню...
Мануалы, которые никак не облегчают порог вхождения и кривую обучения, попутно отбирая самое ценное, что у разработчика есть — время — плохие, негодные, и должны быть преданы огню.
Есть некий сорт снобизма в изыскивании аргументов против систем, облегчающих жизнь разработчика, но в сущности они защищают элитизм и сакральные знания осиливших.
> самое ценное, что у разработчика есть — время — плохие, негодные,
> и должны быть преданы огню.Короче, "смузи не ждёт", да?
В том числе.
> Мануалы, которые никак не облегчают порог вхождения и кривую обучения, попутно отбирая самое ценное, что у разработчика есть — время — плохие, негодные, и должны быть преданы огню.Ны дык разработчики, которые не читают мануалов потом и оставляют за собой тонны дерьма. Посему они должны быть преданы огню.
…не читатель?
Ну что за привычка, выдумать себе образцово-слабый тезис, и красиво его опровергнуть.Ещё раз, на пальцах. «Плохие мануалы, отнимающие время и усилия на их вкуривание» не имеют ничего общего с «плохие разработчики, мануалов не читающие», и вот почему.
Если приспичит, и нет альтернатив, придется всё же жрать что дают, и читать многостраничную лабуду, тут без вариантов. Но с наличием альтернативы ситуация меняется.
Со всякими вспомогательными утилитами вида сборочных систем сходная ситуация. Доведу, пожалуй, до абсурда. Можно потратить часы (и даже дни) для заучивания вывода man javac. Можно за пять минут написать build.gradle.
В первом варианте время разработчика тратится неэффективно. Во втором обратную связь получить гораздо быстрее.
> Плохие мануалыУ GNU make очень хороший мануал.
Если оценивать с точки зрения полноты информации — согласен, он весьма хорош, полон и структурирован.
Но с точки зрения подачи — не всё так радужно.> read the first few sections of each chapter, skipping the later sections.
Сделай сам себе quickstart. И, если в make ещё куда ни шло, то в https://wiki.debian.org/Packaging совсем всё печально с начальным обучением.
> которые время тратят на проектирование и написание полезных штук.
> на проектирование*широченная улыбка*
Не удержался и плюсанул Шигорину. Куда катится этот мир?
Объясните, плз., с чего бы это вдруг make так тормозит (судя по предпосылке авторов проекта) ?
Тут скорее не make, а связка autotools+make. meson - аналог autotools. autotools - по сути нечто подобное sh-скриптам, там тормоза будут, понятное дело. А если ещё учесть, какое количество костылей туда обычно добавляется для совместимости со старыми версиями...А касательно make, то это аналог ninja. По работе я пробовал делать сборку одного и того же проекта через make (-j cpus_count+1) и ninja. По ощущениям слегка быстрее ninja, но замеров не проводил.
> Тут скорее не make, а связка autotools+make. meson - аналог autotools.
> autotools - по сути нечто подобное sh-скриптам, там тормоза будут, понятное дело.Там тормоза не от скриптов, а от тестов. Если "обойтись" без сборки и запуска тестов, результат быстро скатится к "работает только на linux/intel, ну, может, ещё freebsd/arm" (хотя куда же без винды и макоси, как я мог забыть).
> А если ещё учесть, какое количество костылей туда обычно добавляется для
> совместимости со старыми версиями...Здесь бы хорошо смотрелась парочка примеров, как мне кажется. :)
> Если "обойтись" без сборки и запуска тестов, результат быстро скатится к "работает только на linux/intel, ну, может, ещё freebsd/arm"Результаты этих тестов в подавляющем большинстве случаев не используются внутри проекта. А время на них потрачено много.
Ну и: автор либо знает как выкручиваться и выкручивается (о, я на OS/360! значит, ... ), либо все "и так работает", либо "платформа не поддерживается". --- в любом случае смысл в этих тестах в целом отсутствует.
> Результаты этих тестов в подавляющем большинстве случаев не используются внутри проекта.точнее, они используются, но там и так, куда их авторскрипты напихают - то есть там, где и без них бы все работало.
> Ну и: автор либо знает как выкручиваться и выкручивается (о, я на
> OS/360! значит, ... )значит, можно было обойтись просто #ifdef'ом - причем раз уж он потрудился разобраться в тонкостях платформы, значит уж точно в курсе, как ее определить подобным образом - и ifdef'ов уже понатыкал, только не штатных компиляторных, а имени configure.
> , либо все "и так работает", либо "платформа не поддерживается". --- в любом случае
> смысл в этих тестах в целом отсутствует.остается еще банальная лень вручную писать скрипты, умеющие --with-чтото и --enable-както, если проект таки предназначен для сборки разными способами и в разных окружениях - проще заставить autoconf нагенерить. Ну а что при этом он еще тонны мусора протестирует и нагенерит - неизбежное зло. Это и есть, пожалуй, 99% всех реальных причин использования автотулзов.
(ну и еще почему-то - паническая боязнь сделать user-editable makefile, что-вы, что-вы, это ж немодно - юзер привык ключики в командной строке копипастить)проекты с самопальной configure без ненужых тестов попадаются раз на сотню, проекты без configure с банальной правкой удобочитаемого makefile - раз на тысячу. И когда потом надо пересобрать чуть по-другому, у тебя остается этот файл, а не config.status невменяемый, или феноменальная память всех ключиков, использованных прошлый раз.
>user-editable makefileВ простейших случаях можно сделать несколько целей, например min/max/default.
>паническая боязнь сделать user-editable makefile1. могут быть конфликты при обновлении
2. если хочешь отправить свои патчи, оттуда придётся это выколупывать
> 1. могут быть конфликты при обновлениимогут, но мерж обычно справляется, я даже не всегда замечаю вовремя.
А когда не справляется - поверь, makefile легче чинить чем сложный .am> если хочешь отправить свои патчи, оттуда придётся это выколупывать
тогда это фиговые патчи - раз ты патчил специфический вариант сборки, ты запросто мог сломать неспецифический. А для тестирования - что configure перезапускать в отдельной помойке, что makefile сказать revert. (а, ну да, тестировать же немодно, фигак-фигак, в CI/CT, если что, через 17 минут откатит как было. Это, что характерно, в системе, настраиваемой через makefile ;)
> Там тормоза не от скриптов, а от тестов.которые, кстати, не нужны.
> Если "обойтись" без сборки и запуска тестов, результат быстро скатится к "работает
> только на linux/intel, ну, может, ещё freebsd/arm"Миша, а ты много видел auto-хернь-прожектов, работающих сами по себе - ну вот хотя бы на всем перечисленном?
Лично я - ни одного, во всяком случае, сложнее hello.c (которому они и не нужны).Зато отлично помню раннюю версию mono - там был мало того что autotools, причем непременно еще руками требовалось создать ему правильное окружение и запускать каким-то хитрым образом - так оно еще и работало...уп-с, только и исключительно под линуксом (и то не всяким). А для любой другой системы выдавало "а вот напишите-ка с нуля этак тыщ пятнадцать строчек кода, а то мы что-то нишмагли". Спрашивается - а зачем вы притащили в проект всю эту скриптовую пакость, если оно у вас все равно на единственной системе работает?
Напрашивающийся ответ - неумение таки пользоваться банальным инструментарием в виде make, компилятора и линкера, и непонимание, как вообще это делают - вероятнее всего, из-за привычек, сформированных visual c.
а по-настоящему (то есть решает реально существующие проблемы, а не тупo вываливается с ошибкой) autotools нужны дай Б-г одному проекту из ста. И там это тоже - экономия получаса времени разработчика, один раз, ценой сотен часов ожидания пока оно протестирует.
вот интересно, что там авто-тулзы делали в systemd - который существует на единственной платформе?
А зачем каждый раз собирать тесты?
минусуют те, кто никогда не собирал софт, потому что в дистрибутиве он отсутствует/древний/кривой
> минусуют те, кто никогда не собирал софт, потому что в дистрибутиве он
> отсутствует/древний/кривойили те кто знают, как работает configure и "зачем собирать тесты". (не, минус не мой)
Затем, что имелись в виду не тесты, а проверки способностей компилятора/системы/библиотек. Каждый раз их _тебе_ собирать, впрочем, не обязательно: просто не запускай ещё раз ./configure.
> Затем, что имелись в виду не тесты, а проверки способностей компилятора/системы/библиотек. ...Есть наблюдение, что в подавляющем большинстве случаев, результаты этих тестов или не используются или бесполезны. А вот вреда от них (ну, по крайней мере, проблем) огребается весьма прилично.
И таки да, уговаривать сборку на первоосновах (make) сильно проще, чем с наслоениями в виде autotools/CMake/SCons/btjam/.... Теперь ещё meson до кучи.
> А зачем каждый раз собирать тесты?Меня это тоже всегда удивляло. Как-то решил разобраться в этом вопросе глубже и нашел:
https://www.gnu.org/software/automake/manual/html_node/confi...
https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/a...
https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/a...То есть можно один раз прогнать configure и сохранить результаты тестов. Тогда при последующих запусках configure будут исполняться только те тесты, для которых нет результатов.
> сборки и запуска тестов, результат быстро скатится к "работает только на
> linux/intel,То есть Поттеринг -- как дома. Good!
>> Тут скорее не make, а связка autotools+make. meson - аналог autotools.
>> autotools - по сути нечто подобное sh-скриптам, там тормоза будут, понятное дело.
> Там тормоза не от скриптов, а от тестов. Если "обойтись" без
> сборки и запуска тестов, результат быстро скатится к "работает только на
> linux/intel, ну, может, ещё freebsd/arm" (хотя куда же без винды и
> макоси, как я мог забыть).
>> А если ещё учесть, какое количество костылей туда обычно добавляется для
>> совместимости со старыми версиями...
> Здесь бы хорошо смотрелась парочка примеров, как мне кажется. :)Мишка, тыж сможешь по-джедайски ускорить сборку месы хотя-б на процетов 20?
> Тут скорее не make, а связка autotools+make. meson - аналог autotools. autotools
> - по сути нечто подобное sh-скриптам, там тормоза будут, понятное дело.Вы, к Вашемы большому счастью, не имеете ни малейшего понятия, что такое autotools. Шелл-скрипты сами по себе особо не тормозят, да и в make используются они же, только ещё в одной обёртке. А autotools... Это набор макросов и скриптов, обеспечивающий примерно такой workflow: разработчик пишет макросы (частично находит готовые), потом запускает с десяток утилит, которые из этих макросов делают скрипты и подкладывают в дерево исходников ещё пару десятков готовых скриптов, потом всё это даётся пользователю, который уже может сделать ./configure && make. А тормозит оно, потому что сгенерированные в результате configure и Makefile невероятно огромны, к тому же configure для выполнения разных проверок >9000 раз запускает компиляцию мелких тестовых файликов. Профит с этого должен заключаться в переносимости, но на деле вся эта система настолько сложная, что никто не умеет толком ей пользоваться, так что шаг влево, шаг вправо от того окружения, в котором проверяли сборку разработчики, приводит к тому, что всё ломается.
сколько мегабайт зависимостей надо, чтобы собрать "привет <censored>"?
Ага, зашибись.>The main design point of Meson is that every moment a developer spends writing or debugging build definitions is a second wasted. So is every second spent waiting for the build system to actually start compiling code.
И из ихнего же Фака:
>Why can't I specify target files with a wildcard?
>...
>One of the main requirements of Meson is that it must be fast. This means that a no-op build in a tree of 10 000 source files must take no more than a fraction of a second. This is only possible because Meson knows the exact list of files to check. If any target is specified as a wildcard glob, this is no longer possible. ...
>>The main backend of Meson is Ninja, which does not support wildcard matches either, and for the same reasons.
>>Because of this, all source files must be specified explicitly.UPD. *сарказм* Хто хочет вручную описывать 10k файлов системе сборки? А придется.
ждем новость «Представлен первый выпуск утилиты automeson для генерации сценариев для системы сборки meson»
На самом деле маска на файлы даёт очень не предсказуемые баги на разных этапах работы любой системы сборки. CMake тот же разрешает glob но предупреждает что дальнейшие проблемы чисто ваши.
>На самом деле маска на файлы даёт очень не предсказуемые баги на разных этапах работы любой системы сборки.Примеры багов будут или сказания и былины ?
Интеграции с IDE. Выполнение макросов/функций/вызов внешних скриптов со списком файлов что получается по маске. Пересборка проекта без clean, сборка отдельных компонентов если в зависимых частях были заюзаны маски и файлы изменены. Туча их.Если вы спрашиваете примеры значит вы не занимаетесь разработкой. Как наступите на первые грабли приходите доложите.
>Пересборка проекта без cleanЧтобы новые файлы подхватились по маске нужно вообще сносить всю builddir и запускать cmake с нуля
>>Пересборка проекта без clean
> Чтобы новые файлы подхватились по маске нужно вообще сносить всю builddir и
> запускать cmake с нуляВообще то нет.
>Интеграции с IDEQtCreator + cmake - у _меня_ проблем нет.
У всех разное представление о том что должно выполняться в "этой" интеграции c IDE. Так что спорить об этом считаю просто бессмысленным.>Пересборка проекта без clean, cборка отдельных компонентов если в зависимых частях были заюзаны маски и файлы изменены.
Пересборка без clean не возможна как бы. А досборка изменившихся файлов + линковка выполняется нормально как для all так и для любой другой промежуточной цели.
>Если вы спрашиваете примеры значит вы не занимаетесь разработкой.
Ок, видимо работадатель платит мне за раcпитие чая на работе, вам же сквозь экран монитора лучше видно.
> So is every second spent waiting for the build system to actually start compiling codeГы. Время, пока configure шарится по директориям и ищет либы - это потерянное, а время, пока сс компилирует - не потерянное.
> UPD. *сарказм* Хто хочет вручную описывать 10k файлов системе сборки? А придется.Там предлагается вызывать внешний скрипт для вывод списка файлов, удовлетворяющего определённым условиям. Но при таком подходе вся хвалёная производительность теряется. И вообще, не факт, что Meson существенно быстрее autotools, так как все тесты у них приводятся с запуском ninja, т.е. весь прирост скорости в основном благодаря ninja. С тем же успехом можно cmake с ninja использовать и получить аналогичную производительность.
> не факт, что Meson существенно быстрее autotools, так как все тесты
> у них приводятся с запуском ninja, т.е. весь прирост скорости в
> основном благодаря ninja. С тем же успехом можно cmake с ninja
> использовать и получить аналогичную производительность.Пишешь как будто autotools и cmake работают с одинаковой скоростью.
В русском языке нет слов "ихнего".
http://slovarozhegova.ru/word.php?wordid=10331
http://ushakovdictionary.ru/word.php?wordid=22275
> В русском языке нет слов "ихнего".В русском языке нет слова "anonymous". Жопа есть, а слова нет )
> Ага, зашибись.
>>The main design point of Meson is that every moment a developer spends writing or debugging build definitions is a second wasted. So is every second spent waiting for the build system to actually start compiling code.
> И из ихнего же Фака:
>>Why can't I specify target files with a wildcard?
>>...
>>One of the main requirements of Meson is that it must be fast. This means that a no-op build in a tree of 10 000 source files must take no more than a fraction of a second. This is only possible because Meson knows the exact list of files to check. If any target is specified as a wildcard glob, this is no longer possible. ...
>>>The main backend of Meson is Ninja, which does not support wildcard matches either, and for the same reasons.
>>>Because of this, all source files must be specified explicitly.
> UPD. *сарказм* Хто хочет вручную описывать 10k файлов системе сборки? А придется.Осиль уже sh, а то он с systemd совсем зачах.
А если сравнить по скорости c cmake. У него тоже есть генератор для ninja.
Да, нечего тут сравнивать. Meson - это хипстерский cmake на питоне. Пройдет время и он либо превратиться в аналог cmake (наберет все его возможности и станет таким же сложным) либо авторы его забросят, либо начнут писать новую, более правильную (и несовместимую) версию.Тут https://www.youtube.com/watch?v=bsXLMQ6WgIk про то, как нужно использовать cmake в современном стиле, а не в привычном виде а-ля v2.8.12.
В текстовом виде есть?
> В текстовом виде есть?Вот pdf:
https://github.com/boostcon/cppnow_presentations_2017/blob/m...
Это все хорошо, но только когда CMake 3.9 появится на Ubuntu 12.04? Ответ - никогда. LTS тормозят внедрение таких подходов.
Соберите из исходников, там нет никаких сложностей. У меня для этого скрипт написан.
Если ваш проект только для внутренних нужд - нет проблем. Если проект - библиотека, от которой зависит сборка других проектов, устанавливаемых в систему пользователя, то такой подход не приемлем. С точки зрения пакаджера дистрибутива, конечно же.
> Соберите из исходников, там нет никаких сложностей. У меня для этого скрипт
> написан.Ммм? Скрипт для сборки системы сборки? Мы все умрём.
Ну Gentoo довольно давно существует. И не кто там не умер еще
Не бойся! Мы пережили компилятор компилятора, а скрипт сборки системы сборки это фигня
А когда появится Meson 0.42 на ubuntu 12.04?
Пока сами не принесете..
cmake кстати собрать не очень сложно. В нем очень мало зависимостей. И он прекрасно работает с cpack. Весь процессgit clone https://github.com/Kitware/CMake
cd CMake/
mkdir b
cd b
cmake ..
make -j9
cpack -G DEB .
sudo dpkg -i cmake-3.9.20170816-g131af-Linux-x86_64.deb
Теперь повтори то же на деплое в 1000 установок.
Так деплоится-то уже собранный пакет. Хотя зачем cpack — не понимаю, бекпортировать пакет из testing/sid гораздо проще и безопаснее.
12.04 + 5y = ваш дистр протух => под него не появится ничего нового от слова "совсем".
Если meson нормально осилит кросскомпиляцию, то пусть будет.
Всем вышеотметившимся "кукарекалам":Я к нему скептически относился, мол хипсторы атакуют, нафик нужно, "комикс_про_14_стандартов.jpg" итд итп
но на практике внезапно оказался удобным
из зависимостей - "только" питон3 + ninja для самой сборки
по использованию нечто среднее между стандартным configure и смакеконфигурить надо в отдельной директории, а не в самих сырцах
аля meson --prefix=/usr/local итп
опции проекта передаются через -D как в cmake
итого
meson --prefix=/usr/local -Denable-somelib -Ddisable-another-libкросскомпиляция искаробочная, работает прекрасно, надо создать файлег с подсказками (хто у нас cc итп) и передать meson-у , тоже типа как у cmake -DCMAKE_TOOLCHAIN_FILE
из минусов:
документации и примеров "маловато будет"
>[оверквотинг удален]
> конфигурить надо в отдельной директории, а не в самих сырцах
> аля meson --prefix=/usr/local итп
> опции проекта передаются через -D как в cmake
> итого
> meson --prefix=/usr/local -Denable-somelib -Ddisable-another-lib
> кросскомпиляция искаробочная, работает прекрасно, надо создать файлег с подсказками (хто
> у нас cc итп) и передать meson-у , тоже типа как
> у cmake -DCMAKE_TOOLCHAIN_FILE
> из минусов:
> документации и примеров "маловато будет"/usr/local? Главное чтобы он умел в RPATH генерировать переносимые бинарники не привязанные к конкретному каталогу. Нужно быть мазохистом чтобы отлаживать свой проект в /usr/local.
> из зависимостей - "только" питон3Знали бы Вы, сколько копать до возможности сборки этого самого py3 при раскрутке на новой архитектуре... хотя, видимо, догадываетесь, раз кавычки поставили ;-)
> Новость о сборочной системе на py3
> сказания о раскрутке оного py3 на новой архитектуреСова порвется, не натягивай. Пожалуйста.
знаю
у меня свой наколенная недо-ось есть, для малинок
всё кросскомпилится
так что _оба_ питона надо собирать по 2 раза ...
>> из зависимостей - "только" питон3
> Знали бы Вы, сколько копать до возможности сборки этого самого py3 при
> раскрутке на новой архитектуре... хотя, видимо, догадываетесь, раз кавычки поставили ;-)Эльбрусы покорять - это вам не комментами плеваться.
Рукожопы ниосиляторыpip install Meson
Collecting Meson
Downloading meson-0.42.0.tar.gz (1.0MB)
100% |████████████████████████████████| 1.0MB 607kB/s
Complete output from command python setup.py egg_info:
Traceback (most recent call last):
File "<string>", line 1, in <module>
File "/tmp/pip-build-wKfiQB/Meson/setup.py", line 20, in <module>
from mesonbuild.coredata import version
File "mesonbuild/coredata.py", line 16, in <module>
from pathlib import PurePath
ImportError: No module named pathlib
Питон версии < 3.4? Ну что поделать, опять мировой заговор рукожопов обломал сурового аналитега
> Питон версии < 3.4? Ну что поделать, опять мировой заговор рукожопов обломал
> сурового аналитегаПитон как обычно демонстрирует чудеса совместимости. Поэтому теперь до того как собрать программу - придется поставить 2 сборочные системы (ninja и meson) и произвести раскопки правильной версии питона. А через полгода окажется что версия питона в системе опять не та.
> Рукожопы ниосиляторы
> pip install MesonЯснопонятно.
> root@localhost / # pip installпофиксил, а то не все сходу смогут оценить нерукожопность осилятора.
Ура наконец-то подох Autotols ...
А чего ты так радуешься-то? Пользователю сборочной тулзы по большому счёту пофигу, чем собирать. Какие команды прописаны в README, те он и вобъёт в консоль. А программер волен сам решать, чем будет собираться его проект.
> Ура наконец-то подох Autotols ...На автокрапе ещё будет написана система сборки того утилизатора, в аппаратный /dev/null которого уйдёт последний мазон :] почти (ц)
>> Ура наконец-то подох Autotols ...
> На автокрапе ещё будет написана система сборки того утилизатора, в аппаратный /dev/null
> которого уйдёт последний мазон :] почти (ц)Михаил, займитесь уже делом. Когда новорожденный удав будет уже ютиться на горах Кавказа?
На их собственной вики написано, что к реальной работе его лучше не подпускать.
> использующей вместо утилиты make инструментарий NinjaА типа cmake так не может? :) Школотроны
> - Поддержка Pkgconfig для обработки дополнительных cflagsЭто точно анонс версии 0.42, а не 0.001prealpha? Очень яркий штрих, между прочим.
Яву-то на кой хрен они поддерживают? Какой вменяемый жабакодер перейдет на ЭТО?
> вменяемый жабакодерНельзя на ноль делить.
Грешновато троллить убогих. Он и так на жабе пишет, так тут ещё и мезоном в голову прилетело.
> Грешновато троллить убогих. Он и так на жабе пишет, так тут ещё
> и мезоном в голову прилетело.Эй, благородные, сделайте мне Sweethome 3D без жабы, ну или альтернативой поделитесь.
> По сравнению с Autotools время сборки GTK+ сократилось в три раза.
> сборка Mesa при помощи Meson оказалась в 4 раза быстрее при первом запуске и в 10 раз быстрее при повторном.Это просто фантастика какая-то. Если всё действительно так, как описывают разработчики, то пожелаю проекту удачи и долгих лет процветания!
>Это просто фантастика какая-то. Если всё действительно так, как описывают разработчики, то пожелаю проекту удачи и долгих лет процветания!Собирал одну из git-версий aseprite (еще когда можно было и ниндзей и обычным мэйком) ради интереса обеими. Разницы особой не заметил.
>>Это просто фантастика какая-то. Если всё действительно так, как описывают разработчики, то пожелаю проекту удачи и долгих лет процветания!
> Собирал одну из git-версий aseprite (еще когда можно было и ниндзей и
> обычным мэйком) ради интереса обеими. Разницы особой не заметил.У aseprite почти нет проверок API компиляцией (он все зависимости из third_party перекомпилит скорее), когда как сборка Mesa и GTK - сама суть проверки возможностей системного окружения.
Я очень сильно подозреваю, что разрабы gtk+ не осилили non-recursive automake (или им просто лень)
Осталось понять, что на самом деле проверяется при декларациях видаdependency('gtk+-3.0')
Что-то мне подсказывает, что это отсылки к pkg-config.
> Что-то мне подсказывает, что это отсылки к pkg-config.Это гипотеза. Чтобы проверить --- надо рыть. ;)
А pkg-config в случае как cross-build, так и текущей разработки использовать сложно.
> Это гипотеза. Чтобы проверить --- надо рыть. ;)Да, это гипотеза. Но мне неинтересно её проверять. Кому интересно, тот пускай и занимается этим.
> А pkg-config в случае как cross-build, так и текущей разработки использовать сложно.
Именно поэтому не помешало бы все эти сложности инкапсулировать.
> Состоялся релиз сборочной системы Meson 0.42, использующей вместо утилиты make инструментарий Ninja.На питоне. Так в чём отличие от waf? Потому что waf не гномовцы@RedHat придумали?
> Сборочная система Meson c большим интересом была воспринята некоторыми крупными открытыми проектами.
Так они же тоже в RedHat, так что неудивительно.
> Предельно читаемые и дружественные пользователю правила сборки, задаваемые на неусложнённом предметно-ориентированном языке.
Только бы не вышло, как с cmake: мало шаблонов как с autotools. В результате каждый придумывает свой стиль, и быстро разобраться выходит даже сложнее.
> Поддержка повторяемых сборок, при которых запуск сборки в разных окружениях приводит к идентичному результату;
А нынче часто собирают без -jX? Или они каким-то чудом и порядок при параллельной компиляции могут сделать воспроизводимым без потерь производительности?
Вобщем, с тормозным стартом autotools, конечно, надо что-то делать. Но он тормозной, потому что там куча проверок да ещё и с отдельной компиляцией на каждый. Не понимаю, как это можно честно ускорить, не выбросив тесты?
Вот make - да, ускоряется ninja, но тут уже meson не причём.
Разве порядок сборки влияет на итоговое содержание бинарников?
Почему-то захотелось увидеть make переписанный на лисп с идеальной структурой оформления кода и данных.
ASDF?
> Почему-то захотелось увидеть make переписанный на лисп с идеальной структурой оформления
> кода и данных.В make функции на scheme добавили :)
> Почему-то захотелось увидеть make переписанный на лисп с идеальной структурой оформления
> кода и данных.Ты ляг поспать и увидишь.
Надеюсь make все-таки останется на libgtk+ и gnome!
Ну если разработчик, не осилил сборочный инструментарий это его проблема. У каждого свое понятие удобства и эффективности. Да и разнообразие, это хорошо
> Ну если разработчик, не осилил сборочный инструментарий это его проблема.не-е-е, ребята - это ВАША проблема. Потому что вам с результатами его неосиляторства жить - или придется переписать весь мир самим.
Я бы эти проекты еще и подальше послал бы, не только в Meson.
какое-то шило на мыло -- и тот и другой выдумывают свои языки для описания правил сборкия не могу найти ни одной логической причины не использовать guile/lua/python/js вместо
в текущем виде больше похоже на очередную попытку редхата тянуть на себя одеяло