И ты, Брут...

На десяточке, убогий автотулс конфигурирует ffmpeg в два раза дольше, чем он потом собирается. Лучшая демонстрация убогости автотулзов.

но ffmpeg не использует autotools, там самописный велосипед

иксмл-я

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

Хотя чего от курочки ещё ожидать…

К тому, что Make сливает Ninja даже на Linux’е. А уж на Windows, где эти make -jN форкаются в проходах по каталогам, всё ещё обстоит печальнее.

В OSS в последнее время тенденция избавления от autotools и make и, учитвая ограниченность и медлительность этих инструментов, я считаю что это прогресс.

Боже, Make вообще был за два дня на коленке кем-то там написан с захардкоженными табами и 20 видами хакерских закорючек, .PHONY и прочих костылей вместо адекватных и понятных сущностей.

Есть такая система сборки, называется tup.

Работает на Linux, Windows, Mac OS.

Скрипты можно писать на встроенном DSL, либо сразу на lua.

Обходит каталоги любой вложенности. Не нужно делать рекурсивные вызовы как в случае с make. (На самом деле и в случае с make не нужно, если заморочиться, но оставим ракетную науку в стороне – инженеры пугаются непонятных слов.)

Рисует в процессе сборки прогрессбары с оценкой оставшегося времени и количеством обработанных целей.

Не зависит ни от чего лишнего, всё упаковано в один бинарь:

$ ldd /usr/bin/tup
	linux-vdso.so.1 (0x00007ffc62ba7000)
	libpcre.so.1 => /usr/lib/libpcre.so.1 (0x00007fe26b990000)
	libfuse.so.2 => /usr/lib/libfuse.so.2 (0x00007fe26b94f000)
	libm.so.6 => /usr/lib/libm.so.6 (0x00007fe26b809000)
	libpthread.so.0 => /usr/lib/libpthread.so.0 (0x00007fe26b7e7000)
	libc.so.6 => /usr/lib/libc.so.6 (0x00007fe26b61e000)
	libdl.so.2 => /usr/lib/libdl.so.2 (0x00007fe26b618000)
	/lib64/ld-linux-x86-64.so.2 => /usr/lib64/ld-linux-x86-64.so.2 (0x00007fe26bbc0000)
$ du -h /usr/bin/tup
1,4M	/usr/bin/tup

Единственный недостаток: на Linux нужна fuse. Не знаю, как это работает на винде, но на произвольный unix-like типа bsd, видимо, не портируешь. Но я думаю, это вполне решаемо, если захотеть.

Нет, мы будем восхищаться убожеством на питоне.

на скольких платформах запускается твой софт

а можно это дело как-то опротестовать, создать инициативную группу с требованием «запилите наши автотулзы обратно!»? :)

Нет никакой разницы на чём оно написано. Scons был угрёбищем не потому что был на питоне, а потому что даже системой сборки толком не был.

А у некоторых и того не получается, они могут только в тьюринг-неполный DSL.

Кстати да. Автор мезона преподносит тьюринг-неполноту как достоинство (мол, ненаговнокодишь), но из моего сугубо личного опыта – это огроменный минус. Впрочем, такая «тьюринг-полнота» как например в makefile – тоже нафиг не нужна: очередной специфический синтаксис с очень ограниченными возможностями. А вот если взять например java/scala, то sbt по удобству и гибкости на три головы круче того же maven как раз в силу того что билд-скрипт – полноценная программа на скале, которая сама по себе – супер-мощный и супер-выразительный язык. Один и тот же язык и в проекте, и в билд-скрипте – идеально.

java/scala, то sbt

Если брать java/scala для билд-скриптов, то вместо sbt будет cbt.

Этому миру нужен герой…

Который окончательно покончит с autotools? Давно нужен.

Gradle с Groovy и Kotlin тоже интересен для Java/Scala/Kotlin.

я вот один опенсорс-проект на автотулзы перевожу, с cmake-а :)

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

lua, кстати, тоже придется собираться с нуля (хотя усилий на это надо гораздо меньше, признаю)

Я не использовал scons, не знаю, как оно, но meson красавчик. Хрен с ним, питоном, он один фиг уже в каждой кофеварке.

2020-05-11 This removes support for autotools in favour of meson.

Наконец этот набор костылей закопали.

Ну и зачем такой хлам, который даже не поправить? Не лучше ли использовать систему сборки, которая работает в 1 стадию, а не в 100500 стадий, 100499 из которых имеют нечеловекочитаемый текст файлов?

Если уж такой фанат sh, то почему бы просто не писать build.sh?

Сколько тебе заплатил Билл Гейтс за эту диверсию?

Это сраный питон на системном уровне не нужен.

Нужен. На нём проще, читаемее и выразительнее писать, чем на bash. Доступна поддержка многих сторонних библиотек. Не нужно всё экранировать. Большие программы на bash - это ужас какой-то. Да ещё и тормоза, т.к. он запускает процессы по любому поводу.

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

Ну так коммунити будет с радостью жрать любое дерьмо от корпораций, но ни за что не поддержит проект от инди-разработчика.

Забавно вспоминать, как годы назад местные линуксоиды обвиняли BSD, что те сос^Wбесплатно работают на корпорации. Теперь линуксоиды сошлись на том, что BSD сдохло, вспоминать о нём вообще не нужно, и ничто не мешает сос^Wбесплатно работать на корпорации самим.

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

Нормально там с ресурсопотреблением. python (3.7.4): 4.79 MB.

Нисколько, исключительно из идейных соображений! Несу благодать автотулзов в необразованные массы!

Ну make конечно медленнее ninja, но формат makefile мне как-то больше нравится. Хотя недостатки есть и у него

lua, кстати, тоже придется собираться с нуля (хотя усилий на это надо гораздо меньше, признаю)

Откуда его собирать? Он прямо в сорцах этой tup лежит, и компилируется всё сразу. . Это встраиваемый язык, адекватный задаче, а не general-purpose молотилка чисел с огромными сорцами.

Нисколько, исключительно из идейных соображений! Несу благодать автотулзов в необразованные массы!

Ваще огонь.

Сколько христианских младенцев в день съедаешь, сатанистская твоя рожа?

Никто ж тебе не запрещает править исходники. Именно исходники, а не генерированную портянку. Стадии не просто так придуманы, собирает в итоге Make

Ну и зачем такой хлам, который даже не поправить? Не лучше ли использовать систему сборки, которая работает в 1 стадию, а не в 100500 стадий, 100499 из которых имеют нечеловекочитаемый текст файлов?

Нет, не лучше.

Система сборки – это make, ninja, tup, etc.

А ./configure – система конфигурирования.

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

Ну так коммунити будет с радостью жрать любое дерьмо от корпораций, но ни за что не поддержит проект от инди-разработчика.

Коммунити будет брать то, что более распространено и протестировано. tup выглядит интересно и я жалею, что не слышал о нем раньше, но хелловорлды на локалхосте писать – одно дело, а тратить время на починку багов в чужом проекте вместо работы над своим, когда он пошел чуть дальше локалхоста, уже совсем не хочется. Я вполне могу понять разработчиков pacman.

Я и говорю, это гораздо проще, чем сборка минимального питона.

У scons есть одна, для многих неудобная, фича - изолированность сборочного окружения. Куда иногда не очень просто передать переменные окружения.

Надо бы м порядком вызова подкаталогов в сезоне разобраться.

Коммунити будет брать то, что более распространено и протестировано.

Жаль, Столлман не знал. И его коллеги не знали.

И Торвальдс в другой части глобуса не знал.

А то сидели бы вы все сейчас на проприетарной Соляре или AIX-е каком – но только те, кто на достаточно крупных предприятиях работает. А остальные на винде, так уж и быть.

Я думаю, это было бы справедливо для этого «коммунити».

Ну так коммунити будет с радостью жрать любое дерьмо от корпораций, но ни за что не поддержит проект от инди-разработчика.

А у вас прям корпорациефобия? Что, даже в домах не живёте, на транспорте не ездите и еду сами выращиваете?

Коммунити будет жрать то что вкусно, а кто это произвёл интересно только фанатикам. Не нужна непереносимая маргинальная поделка от инди-разработчика никому, примите это.

Откуда его собирать? Он прямо в сорцах этой tup лежит, и компилируется всё сразу

Ну бандлинг зависимостей однозначно указывает на то что автор некомпетентен и от его поделки лучше держаться подальше.

Это встраиваемый язык

С массивами с единицы это вообще не язык.

IO на винде в принципе убогий

Сейчас byko3y расскажет какой крутой асинхронный IO в ядре Windows.

Уверуйте в автотулзы, господа! Достаточно потратить лишь немного своего времени на освоение документации, чтобы проникнуться мощью и продуманностью истинной системы сборки GNU build system! Нет системы сборки, кроме GNU Build System и Autoconf, Automake, и Libtool пророки его!

http://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.69/autoc...

http://www.gnu.org/software/automake/manual/automake.html

http://www.gnu.org/software/libtool/manual/libtool.html

Освой автотулзы сам и поделись с ближними! Твои волосы станут мягкими и шелковистыми! А твои программы будут исполняться быстро и безбажно на любой платформе с минимумом потребляемых ресурсов!

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

Единственный недостаток: на Linux нужна fuse.

Ну вот зачем ему FUSE?

Ждем следующую «очень простую» систему сборки, которой для работы нужно будет вытащить привилегированный докер-контейнер на полтора гига, который помимо прочего будет содержать базу данных Oracle, копалку биткойнов и ноду какого-нибудь ботнета, что мелочиться-то уж.

Заметьте, только автотулзы являются столлманоугодным ПО

http://www.gnu.org/software/software.html

на этой странице в списке свободных программ вы нигде не найдёте этих ваших еретических симейков, сконсов и мезонов. А если их там нет, значит очевидно они не нужны, вредны и опасны!

Ну так почему нельзя сделать человекочитаемый configure?

Выросло поколение, которое не знает sh и m4?

И это хорошо. Поколение, которое знает - это как посттравматический синдром после участия в военных действиях, препятствующий нормальной жизни.

А зачем его делать человекочитаемым? Человекочитаемыми должны быть только исходники, откуда configure генерируется, автогенерируемые тексты программ никому не обязаны быть человекочитаемыми. Это один из принципов юникс-вея

Коммунити будет жрать то что вкусно, а кто это произвёл интересно только фанатикам. Не нужна непереносимая маргинальная поделка от инди-разработчика никому, примите это.

Да согласен. Скоро уже, скоро выкинем gcc, binutils. coreutils и прочие убогие поделки инди-разработчиков.

Ну бандлинг зависимостей однозначно указывает на то что автор некомпетентен и от его поделки лучше держаться подальше.

Да куда уж глупым до экспертов.

Чтобы не было скриптов, которые генерируют скрипты, которые генерируют скрипты.

Ну так почему нельзя сделать человекочитаемый configure?

Может еще человекочитаемый ELF сделать?

Скриптовик не слышал про компиляцию.

Автор мезона преподносит тьюринг-неполноту как достоинство (мол, ненаговнокодишь), но из моего сугубо личного опыта – это огроменный минус.

Это именно достоинство, потому что тьюринг-полнота ломает инкрементальную сборку. Хотите тьюринг-полноту - делайте дополнительные таргеты и запускайте внешние программы/скрипты.

Каждый компонент в этой цепочке делает что-то одно и делает хорошо. Ты предлагаешь писать монструозную программу на все случаи жизни, которая делает всё сразу, конфигурацию и сборку. Всех вариантов она всё равно не предусмотрит, будет убогой и глючной. Например, как CMake.

Представь, что ./configure это бинарник, и относись к нему соответствующим образом

Да согласен. Скоро уже, скоро выкинем gcc, binutils. coreutils и прочие убогие поделки инди-разработчиков.

Ну, например, те кто попродвинутей уже давно на clang и gold. От аппле и гугла, но это не важно.

Ну, например, те кто попродвинутей уже давно на clang и gold.

Зачем gold, если есть lld?

«LLD got faster [..] At the beginning of this year, LLD took about 16 seconds to produce a 1.5 GB clang (debug build) executable. Now, it takes about 14.5 seconds on single core and 8.5 seconds on 20 cores. ld.gold takes about 25 seconds and 20 seconds, respectively. [..] If you have a problem of too long link time, I’d recommend to try LLD.»

Чтобы не было скриптов, которые генерируют скрипты, которые генерируют скрипты.

meson генерирует скрипты ninja. Что же делать? Срочно выкини meson!

И вот эти «разработчики» берутся рассуждать о преимуществах разных систем сборки.

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

У меня на sbt ничего она не ломала. Подробностей сейчас уже не вспомню, но может просто руки были прямые?