X.Org, ещё один проект отказывается от autotools

чем оно лучше cmake ?

Я сам пользуюсь cmake.

Я с помощью meson собирал лишь несколько hello-world в gnome builder.

Тут они пишут, что

1. их язык конфигурации самый простой и намного проще cmake

2. meson самая быстрая система сборки

https://mesonbuild.com/Simple-comparison.html

The fastest build system see measurements, user friendly, designed to be as invisible to the developer as possible, native support for modern tools (precompiled headers, coverage, Valgrind etc). Not Turing complete so build definition files are easy to read and understand.

https://mesonbuild.com/Comparisons.html

А ещё на meson перешли Gnome и GTK, а также Mesa, Weston, systemd, sway, DXVK…

Я думаю autotools удалят из реп раньше чем X.Org.

не дождётесь!

судя по доке она не собирает, а генерирует ninja файлы

я относительно недавно перевёл один свободный проект с б-мерзкого симейка на божественные автотулзы

Давно пора. Автохлам должен сдохнуть.

чем оно лучше cmake ?

Хоть meson и говно, но даже он лучше cmake. Боже, что вообще может быть хуже cmake? Даже шел-скрипт вместо системы сборки будет лучше драного cmake.

я относительно недавно перевёл один свободный проект с б-мерзкого симейка на божественные автотулзы

А вот этот пользователь шарит.

Кофе за мой счёт.

Там вроде где-то альтернативную реализацию meson на каком-то компилируемом ЯП делали вместо пузона?

Она жива?

после того, как Xorg сломали API и тем самым прекратили поддержку старых драйверов (читай карт) в районе 1.21, я не удивлюсь никакой глупости от них.

Я думаю autotools удалят из реп раньше чем X.Org.

Мне тут потребовалось немножко дописать программу на крестах, которая собирается автотулзами и последний раз релизилась в 2004-м с бог знает какой версий автотулзов.

Ну я написал в терминале autoreconf -i && ./configure --prefix=$HOME/tmp && make && make install, и всё, что характерно, собралось на свежих автотулзах и свежем компиляторе.

Ждём историю узбека от ваших хипстеров через 15 лет.

Я тоже отказался от autotools, если вам интересно.

во-во

cast EXL.

Вроде давно уже X.Org перешёл на Meson. Пора уже и GCC перевести, а то там какой-то ужас со системой сборки.

чем оно лучше cmake ?

Писанины меньше и легче читается.

make && make install

В чём смысл этого ритуала если сразу make install работает без проблем?

Вроде давно уже X.Org перешёл на Meson

Может там какое-то время было две системы сборки?

Комит от 27.10.2021, то есть два дня назад всего:

https://cgit.freedesktop.org/xorg/xserver/commit/?id=c97397dc47f7a25858052f52dd9396ec564065b4

Боже, что вообще может быть хуже cmake?

Autotools.

Ждём историю узбека от ваших хипстеров через 15 лет.

Jam в BeOS/Haiku уже довольно давно работает. И он намного читабельнее Autotools и Cmake.

Мне тут потребовалось немножко дописать программу на крестах, которая собирается автотулзами и последний раз релизилась в 2004-м с бог знает какой версий автотулзов.

А мне потребовалось скомпилировать сложный проект на autotools’ах, который называется gcc-3.4.3 в современном дистрибутиве Linux и это вылолось в получасовой пердолинг, который я так и не закончил. В итоге пришлось как эти ваши хипсторы делают – брать контейнер (древнюю виртуалку RHEL 7) и собирать всё там.

Cmake страдает большим числом всяких кривых плагинов для поиска библиотек. Договорились бы уже использовать только pkgconfig, по крайней мере для UNIX-like систем.

GNU Poke 1.0

новый свободный проект, вышедший в 2021 году, использует автотулзы для сборки

GNU Poke 1.0

GNU

Не нужно.

чем оно лучше cmake ?

Всем. Что autotools, что cmake – эталонные примеры того, как НЕ нужно проектировать сборочные системы. Надеюсь, после смерти autotools отовсюду ссаными тряпками погонят уже CMake. RedHat, как видно, уже погнал CMake из своих проектов: GNOME, софт под GNOME, X.Org, Wayland, Mesa и systemd не собираются CMake’ом и правильно делают.

Привет.

Мне тоже что-то подобное скоро предстоит, напердолюсь…(

Таки проблема-то в автотулзах или в особенностях самого gcc?

спорим, что у него пользователей больше, чем у Haiku

Всем. Что autotools, что cmake – эталонные примеры того, как НЕ нужно проектировать сборочные системы.

Решил заменить на несборочную несистему? =)

Jam это аналог make, нет?

Cmake более гибкий и универсальный, чем Meson. В Meson много чего прибито в коде на Python что в Cmake можно реализовать средствами самого языка сборки. Тоже самое про Jam, он гибче Meson.

Meson хорош пока его функционала хватает.

Писанины меньше и легче читается.

Спорно. На мой скромный взгляд, у meson синтаксис куда более мерзкий, чем у современного cmake.

А уж документация у cmake выше всяческих похвал, у meson же какое-то недоразумение.

https://packages.gentoo.org/packages/sys-devel/autoconf/reverse-dependencies

ждать можно бесконечно

С технической стороны да, он сам собирает, а не генерирует Makefile/Ninja. Но он более гибкий и у него более читабельный синтаксис. На нём вполне можно писать большие сложные проекты. На голых Makefile это сложнее.

Да, все проблемы CMake на ЛОРе обсосаны уже давным давно и не по одному кругу:

1. Оценки хелловорлда тред (комментарий)
2. За что так не любят cmake? (комментарий)

Забавно что до сих пор находятся некоторые фанатики облизывающие CMake. Даже несмотря на все эти архитектурные проблемы, которыми кишит CMake, им даже чисто эстетически пользоваться противно: регистронезависимость прямиком по традициям винды, когда в разных проектах по разному определено:

TARGET_LINK_LIBRARIES(program mylib)
target_link_libraries(program mylib)
Target_Link_Libraries(program mylib)
Target_link_libraries(program mylib)

А то и в одном и том же проекте или даже файле. DSL в файлах с расширением *.txt, который не отвечает смыслу и т. д.

Непонятно почему эта мразь так набрала популярность. Во истину в IT зачастую выигрывает самое наркоманское и ублюдочное решение: PHP, CMake, autotools, etc.

Таких проектов много было и есть. Я с jam как-то сталкивался еще больше то ли 10, то ли 15 лет назад.

Есть хорошо проработанные, есть перспективно-недописанные.

Но проблема кодерского сообщества в том, что все будут 30 лет пользоваться убогим make, а потом корпорация выкатывает кривой велосипед, сваренный в гараже из обрезков ржавой трубы и колёс от телеги, и все бегут обмазываться «новой перспективной технологией».

И это сообщество меня слегка подзаколебало.

PHP, CMake, autotools, meson

xd

Jam в BeOS/Haiku уже довольно давно работает. И он намного читабельнее Autotools и Cmake.

А как давно в BeOS используется Jam? Интересно, что именно Jam был выбран в качестве сборочного инструмента для Project Builder (предок Xcode) в первых версиях Mac OS X (10.0). Так как BeOS делали с небольшой оглядкой на Classic Mac OS, они могли заюзать и инструмент который выбрали в Apple.

А как давно в BeOS используется Jam?

Не знаю. Я познакомился с Haiku немного раньше выхода Alpha 1. Про остальное знаю по косвенным источникам. Историю Jam и MacOS специально не изучал.

Мне тоже что-то подобное скоро предстоит, напердолюсь…(

Лучше сразу бери что-нибудь древнее и собирай в виртуалке с машиной тех лет, когда была выпущена версия этого древнего софта. Сэкономишь кучу времени и нервов.

Таки проблема-то в автотулзах или в особенностях самого gcc?

Именно в автотулзах, которыми собирают GCC, потому что во всей этой сгенерированной скриптовой каше без бутылки не разберёшься, оно тупо отрабатывает не так как нужно. У меня ещё и хост x86_64 был, а компилятор нужно было собирать 32-битный.

Ошибки сборки компилятором в сишке редки и фиксятся легко с опытом. А вот ошибки конфигурирования из-за autotools шатают нервы потому что х.з. что делать. А если опыта нет то и подавно.

Не зря ядро не собирается аутотулзами, ох не зря. И благодаря этому, кстати, я вот взял и собрал 2.6.10 у себя на современном хосте, когда мне это было нужно. Удобно.

Что будет, если SOME_LIBS_VARIABLE не будет существовать? CMake скажет, что ты обращаешься к несуществующей переменной? Ничего подобного. Молча прожует и ничего не скажет. Это нелогичное говно. По этой же причине я не люблю эти ваши баши и мейки.

Ну для полноты картины, у GNU make есть --warn-undefined-variables. Правда особо не лучше.

Cmake более гибкий и универсальный, чем Meson.

Конечно сейчас более гибкий. За столько времени его потихоньку довели до состояния «ну вот как-то так можно пользоваться».

История успеха¹: торрент-клиент Flush удалили из Debian из-за того, что он перестал собираться. Никому не захотелось разбираться, что там в основанных на autotools скриптах сборки сломалось. Сейчас его почти ни в каких дистрибутивах нет, хотя раньше был: https://repology.org/project/flush/versions.

¹Сарказм.

Лучше сразу бери что-нибудь древнее и собирай в виртуалке с машиной тех лет, когда была выпущена версия этого древнего софта.

Неспортивно как-то =)

Как же я потом приду с историей успеха про то, как я заставил работать автотулзы? (Ну или не заставил.)

Во истину в IT зачастую выигрывает самое наркоманское и ублюдочное решение:

C++

Python

Как же я потом приду с историей успеха про то, как я заставил работать автотулзы? (Ну или не заставил.)

Нет, ну если тебе ради такого фана: Собираем Perl прямиком из 1987 года то всегда пожалуйста, а если нужно здесь и сейчас и чтобы работало, то проще взять окружение тех лет.

Си. Нет RAII в стандарте в 2021 году.

Три года назад. Но сборку автотулзами оставили. А сейчас выкинули.

потому что во всей этой сгенерированной скриптовой каше без бутылки не разберёшься

в ней не нужно разбираться, разбираться нужно в исходниках, из которых она генерируется

последний раз релизилась в 2004-м

Обычно это означает, что она нахрен никому не сдалась.

собралось на свежих автотулзах

А по несколько версий автотулзов в дистрибутивах просто так собирают, от нечего делать?

Automake 1.11 is the legacy version of automake. The automake package should be preferred and this package should only be used with older software that doesn't support newer versions of automake.