После восьми лет с момента публикации версии 2.69 представлен выпуск пакета GNU Autoconf 2.69b, в котором поставляется набор M4-макросов для создания скриптов автоконфигурации для сборки приложений в различных Unix-подобных системах (на основе подготовленного шаблона выполняется генерации скрипта "configure"). Выпуск позиционируется как бета-версия будущей версии 2.70...Подробнее: https://www.opennet.dev/opennews/art.shtml?num=53361
> После восьми лет с момента публикации версии 2.69Firefox, Chrome и пр., смотрите - остались ещё люди в этой индустрии, которые никуда не торопятся и собирают версии по существу.
Ты мониторишь все статьи чтобы быть первым? А так да, всё по существу.
Да нет, так получается. Вообще настроена RSS лента в браузере да есть подписка на канал в Telegram.
По-существу, главное чтобы быть быстрее тебя, Аноним.
Ты версию less или systemd видел?С другой стороны, а какая разница? Это всего лишь циферка. Главное, чтобы они по порядку шли.
> никуда не торопятся и собирают версии по существуДавай чисто для прикола сравним количество изменений Autoconf 2.69...2.69b и, скажем, хромиумовское 83.0.4103.116...84.0.4147.89.
«по существу» подразумевает полезность изменений, а не скрытие URL в адресной строке или удаление а потом возвращение кнопки «Закрыть все вкладки справа» или вырезанный FTP
Да, корпорация гугл занимается только сокрытием урлов и возвращением свежеубранных кнопок. Посмотри сам: ВСЕ коммиты связаны только с этим - https://chromium.googlesource.com/chromium/src/+log/83.0.410... (жми Next в конце страницы пока не надоест).
сама корпорация дохрена чем занимается помимо Chrome, спору нет
Жаба с гадюкой их все же куснули - "потенциально могут привести к нарушению совместимости с существующими скриптами Autoconf"
>при наличии теперь выбирается компилятор с поддержкой C11 (с откатом до C99 и C89, если не найден), а в AC_PROG_CXX - C++11 с откатом до C++98В 2036 поддержат C++20.
В общем, в топкy.
Вы совершенно не понимаете автотулзы.
А его кто-то кроме авторов понимает?
Махоткин, говорят...PS: в смысле autobook дочитал.
тю, он уже лет 15 как менеджер и автотулз уже давно не его проблемы.
Интересеные у вас в Альте отношения: "Так а ты иди штудируй маны. Чтобы к завтрашнему дню от зубов отскакивало".
Поясняю, автотулзы прозрачны, если не мудрить, они не стоят у вас на пути. Если скрипт не распознает ваш компилятор, то можно просто указать ./configure CC=megacompiler-c-2036. И всё поедет.
AC_PROG_CC ставит OBJEXT and EXEEXT один раз. Второй вызов надо сделать - добро пожаловать в обёрточную шелл-функцию.
Это зависит от платформы, а не от компилятора, и строго говоря, вообще не имеет значения.
> автотулзы прозрачны, если не мудритьНе поможет. Их авторы уже тыщу раз перемудрили.
Согласен. IMO, там целеполагание вышло невменяемое, а результат
соответствует этому целеполаганию.
нужно
Пора уже продвигать mk-configure взамен.
А оно поддерживает столько же неведомой фигни? А то сабж вроде даже под досом можно изгальнуться, с DJGPP каким.
Это которому бсдшный make нужен ? B печку его !
> Пора уже продвигать mk-configure взамен.У него, к сожалению, и другие косяки недавно всплыли. Похоже, при дизайне Лёша такого не ожидал (он в курсе).
> У него, к сожалению, и другие косяки недавно всплыли. Похоже, при
> дизайне Лёша такого не ожидал (он в курсе).Подробности секретны? Можно в почту?
>> У него, к сожалению, и другие косяки недавно всплыли.
>> Похоже, при дизайне Лёша такого не ожидал (он в курсе).
> Подробности секретны? Можно в почту?Подробности публичны, просто тогда меня хватило хотя бы заикнуться, а сейчас вспомнил точнее и нашёл ссылку -- см. окрестности http://lists.altlinux.org/pipermail/devel/2020-May/210939.html
(у меня тоже такое было "ой, об этом не подумал"; немножко утешало разве что когда-то прочитанное в архиве openwall письмо Solar Designer насчёт "ой, а про чрут в чруте не подумал")
Кто в здравом уме сейчас этим пользуется?
КриптоПро. Мы собираем CSP под Linux, macOS, iOS, AIX, FreeBSD, Solaris, Android на intel/power/sparc/arm/mips/эльбрус. И соберём на N+1 платформе и M+1 архитектуре. Никаких аналогов нет.
Врёте, это умеет любая современная система сборки.
Ананим не понимает, что если любая система сборки справляется, то никакая система сборки и не нужна.А вот взять только Линукс и Солярис - там начинаются чудеса: https://www.oracle.com/solaris/technologies/linux-app.html
И даже cmake уже не тянет.
Брехня. У нас даже тупейший boost.build справляется со сборкой под linux, freebsd и solaris, что уж говорить про cmake. А если ты только чужой код умеешь собирать, так речь не об этом.
Угу, когда попробуешь забилдить под AIX или там аль-полено какое - тогда и расскажешь как тебе твой бустбилд.
Под полено тоже собираем, не переживай. Будет надо — и под AIX соберём.
Это ты врёшь, не любая система сборки поддерживает все эти цели.
Да, но тем не менее все легко можно осилить Scons-ом
> Да, но тем не менее все легко можно осилить Scons-омА этот кусок всё того же писали те, у кого даже я принципиальный баг про -Wl,--as-needed нашёл давным-давно. Ну то есть полностью профнепригодные.
Из всех билд систем вы выбрали наиболее отстойную :)
> Врёте, это умеет любая современная система сборки.Врёте здесь Вы. Автокрап оказался вменяемым на фоне того дерьмища, особенно шмяка и _особенно_ waf, которое понаклепали возомнившие себя способными сделать что-то лучше импотенты.
Ещё один врун пришёл… Только про waf — правда, остальное — брехня.
> КриптоПро. Мы собираем CSP под Linux, macOS, iOS, AIX, FreeBSD, Solaris, Android на intel/power/sparc/arm/mips/эльбрус. И соберём на N+1 платформе и M+1 архитектуре. Никаких аналогов нет.Это не аналогов нет, это у вас, похоже, специалистов нет окромя старпёров, которые ничего другого и не видели.
$ ls /usr/share/cmake-3.13/Modules/Platform | sed 's/[-.].*//' | uniq
AIX
Android
Apple
ARTOS
BeOS
BlueGeneL
BlueGeneP
BlueGeneQ
BSDOS
Catamount
CrayLinuxEnvironment
CYGWIN
Darwin
DragonFly
eCos
Euros
FreeBSD
Fuchsia
gas
Generic
GHS
GNU
GNUtoMS_lib
Haiku
HP
IRIX64
IRIX
kFreeBSD
Linux
Midipix
MirBSD
MP
NetBSD
OpenBSD
OpenVMS
OSF1
QNX
RISCos
SCO_SV
SINIX
SunOS
syllable
Tru64
ULTRIX
UnixPaths
UNIX_SV
UnixWare
Windows
WindowsCE
Windows
WindowsPaths
Windows
WindowsPhone
WindowsStore
Windows
XenixP. S. Шта? Xeninx?!
> $ ls /usr/share/cmake-3.13Какие там плюсы были этому поделию нужны для сборки?
(это ещё не затрагивая тот гадюшник из "стандартов", который они сами себе уже устроили)Не видели здесь ничего лично Вы. Ни того ксеникса, ни чего-либо отличного от x86 и, может быть, arm. Латентный винтелоид, как и те шмякоделы.
Ой, ты не осилил патчик для ель-бруса запилить? Ну извиняй, больше это никому не нужно.
Если что, я cmake'ом благополучно собирал проекты под amd64, arm64, e2k-4c, i386 и mipsel. Проблем, связанных именно со сборочной системой, не заметил нигде. Что-то не так делаю, вероятно.
> под amd64, arm64, e2k-4c, i386 и mipselОй, забыл. Ещё под все архитектуры, поддерживаемые Fedora 3-4 года назад.
> Ой, ты не осилил патчик для ель-бруса запилить?Видите ли, патчик для автокрапа потребовался один, несложный и за последующие пять лет не тревожил: http://lists.gnu.org/archive/html/config-patches/2015-03/msg...
Да, порой до сих пор пригождается что-то вроде
---
cp -aLt . -- /usr/share/automake/config.{guess,sub}
--- http://altlinux.org/эльбрус/портирование(в т.ч. и для собираемых cmake проектов вроде clang) -- и да, это издержки статической линковки шелл-скриптов в автоподходе.
Но насколько же это меньше проблем, чем "я не собираюсь cmake менее чем x.y.z", а он, соответственно, уже "переехал на новый стандарт", а новый тулчейн тащить в тяжёлых случаях бывает тоже тем ещё приключением (сейчас про e2k говорю, но на x86 тоже сплошь и рядом бывало).
И плюс ещё приятные мелочи вроде jsoncpp/libuv, в которые Вы тоже, поди, не лезли, потому как всё уже на блюдечке, другими сделанное (но хоть rhash из "странных" зависимостей проблем не доставлял).
Или вот такое: http://gitlab.kitware.com/cmake/cmake/issues/17126
> Что-то не так делаю, вероятно.
У Вас сколько этих проектов? А у меня сейчас -- более семисот из >14000 пакетов в sisyphus_e2k. Причём самого разного авторства и качества (в том числе благодаря и регрессиям при переходе с auto* на шмяк).
PS: заметил, что за cmake нередко агитируют любители винды и макоси -- для них, возможно, он и впрямь подходит лучше.
"дедушка, вы тоже так говорите". Когда доходит до чего-то чуть-чуть нетривиального,
автокрап и cmake стоят друг друга. Концептульная дрянь --- оба. Латать косяки
автокрапа, правда, получается чуть легче (если только авторы весь дебилизм libtool'а
не врубают --- в патологических случаях уже только ампутация).
> Когда доходит до чего-то чуть-чуть нетривиального, автокрап и cmake стоят друг друга.Мой опыт говорит о другом. В cmake всё бывает плохо только в том случае, когда криворукий разработчик накосячил в CMakeLists.txt. Увы, за гибкость инструмента приходится платить возможностью такого. А в автокрапе многое криво by design. Не говоря о необходимости таскать вместе с исходниками гору нагенерированных скриптов, объёмом превышающую сам код проекта, причём зачастую — во много раз.
> Латать косяки автокрапа, правда, получается чуть легче (если только авторы весь дебилизм libtool'а не врубают --- в патологических случаях уже только ампутация).
Без libtool в сколько-нибудь сложных проектах не обойтись, а способов отключить хотя бы часть его дебилизма я как-то не знаю. В простых же проектах a'la helloworld и голого make хватит.
>> Когда доходит до чего-то чуть-чуть нетривиального, автокрап и cmake стоят друг друга.
> Мой опыт говорит о другом.Видимо, я опытнее.
> В cmake всё бывает плохо только в
> том случае, когда криворукий разработчик накосячил в CMakeLists.txt.
> Увы, за гибкость
> инструмента приходится платить возможностью такого. А в автокрапе многое криво by
> design. Не говоря о необходимости таскать вместе с исходниками гору нагенерированных
> скриптов, объёмом превышающую сам код проекта, причём зачастую — во много
> раз.Я не адвокат ни того ни другого. Обе "хороши". И cmake ничуть не лучше.
>> Латать косяки автокрапа, правда, получается чуть легче (если только авторы весь дебилизм libtool'а не врубают --- в патологических случаях уже только ампутация).
> Без libtool в сколько-нибудь сложных проектах не обойтись,Сильно неправда.
> а способов отключить хотя
> бы часть его дебилизма я как-то не знаю.Иногда он не сильно мешает. Иногда его можно заткнуть.
Но встречаются и эпичные случаи.> В простых же
> проектах a'la helloworld и голого make хватит.Для типовых случаев разница в сопровождении не велика
и не принципиальна. Для сложных вещей --- цена сопровождения
систем с "чистыми" make-файлами на два порядка ниже
любой их упомянутых здесь двух.
m4 это жесть, bloatware как оно есть
Сам по себе m4 — не такая уж плохая штука, хоть и с упоротым синтаксисом. Но то, что на нём навертели в сабже — за гранью добра и зла.
Нормуль, новость, одобряю. Ордам нубов наверняка не интересно/не в курсах/не дойдёт, что autoconf умеет не только Си, с плюсами и без, но и кучу других полезных, годных языков. У меня в одном самопильном проектике он даже с bash/ash/*sh пригодился...А когда речь идёт о проекте, написанном на нескольких языках... Да, школота, есть и такие. Что может быть лучше? Я не ругаю другие системы сборки, Cmake мне тоже нравится. Но он пока сыроват. Имхо.
> проекте, написанном на нескольких языкахда-да, тогда обязательно нужен autotools, чтобы запустить gradle, yarn и go build.
Ага тото в каждом проекте сотни сотни миллионы скриптом оберток над ними. Проще некуда ага...
я скажу так: чтобы написать makefile, вызывающий go build, автотуулз явно не нужен и даже мешает.
автотуулз -- это именно генератор makefile, на минуточку.
Чтобы запустить go build, и makefile писать не надо.