https://217.65.3.21/openforum/vsluhforumID3/121266.html После восьми лет с момента публикации версии 2.69 представлен выпуск пакета GNU Autoconf 2.69b, в котором поставляется набор M4-макросов для создания скриптов автоконфигурации для сборки приложений в различных Unix-подобных системах (на основе подготовленного шаблона выполняется генерации скрипта "configure"). Выпуск позиционируется как бета-версия будущей версии 2.70...<br><br>Подробнее: https://www.opennet.ru/opennews/art.shtml?num=53361<br> https://217.65.3.21/openforum/vsluhforumID3/121266.html#56 Mon, 20 Jul 2020 13:06:55 GMT &gt; Ой, ты не осилил патчик для ель-бруса запилить?<br><br>Видите ли, патчик для автокрапа потребовался один, несложный и за последующие пять лет не тревожил: http://lists.gnu.org/archive/html/config-patches/2015-03/msg00000.html<br><br>Да, порой до сих пор пригождается что-то вроде<br><br>---<br>cp -aLt . -- /usr/share/automake/config.{guess,sub}<br>--- http://altlinux.org/эльбрус/портирование<br><br>(в т.ч. и для собираемых cmake проектов вроде clang) -- и да, это издержки статической линковки шелл-скриптов в автоподходе.<br><br>Но насколько же это меньше проблем, чем "я не собираюсь cmake менее чем x.y.z", а он, соответственно, уже "переехал на новый стандарт", а новый тулчейн тащить в тяжёлых случаях бывает тоже тем ещё приключением (сейчас про e2k говорю, но на x86 тоже сплошь и рядом бывало).<br><br>И плюс ещё приятные мелочи вроде jsoncpp/libuv, в которые Вы тоже, поди, не лезли, потому как всё уже на блюдечке, другими сделанное (но хоть rhash из "странных" зависимостей проблем не доставлял).<br><br>Или вот такое: http://gitlab.kitware. https://217.65.3.21/openforum/vsluhforumID3/121266.html#55 Mon, 20 Jul 2020 12:39:00 GMT &gt;&gt; У него, к сожалению, и другие косяки недавно всплыли.<br>&gt;&gt; Похоже, при дизайне Лёша такого не ожидал (он в курсе).<br>&gt; Подробности секретны? Можно в почту?<br><br>Подробности публичны, просто тогда меня хватило хотя бы заикнуться, а сейчас вспомнил точнее и нашёл ссылку -- см. окрестности http://lists.altlinux.org/pipermail/devel/2020-May/210939.html<br><br>(у меня тоже такое было "ой, об этом не подумал"; немножко утешало разве что когда-то прочитанное в архиве openwall письмо Solar Designer насчёт "ой, а про чрут в чруте не подумал")<br> https://217.65.3.21/openforum/vsluhforumID3/121266.html#54 Mon, 20 Jul 2020 10:25:19 GMT &gt; У него, к сожалению, и другие косяки недавно всплыли. Похоже, при <br>&gt; дизайне Лёша такого не ожидал (он в курсе).<br><br>Подробности секретны? Можно в почту?<br> https://217.65.3.21/openforum/vsluhforumID3/121266.html#53 Fri, 17 Jul 2020 08:52:44 GMT Под полено тоже собираем, не переживай. Будет надо &#8212; и под AIX соберём.<br> https://217.65.3.21/openforum/vsluhforumID3/121266.html#52 Fri, 17 Jul 2020 08:16:48 GMT &gt;&gt; Когда доходит до чего-то чуть-чуть нетривиального, автокрап и cmake стоят друг друга.<br>&gt; Мой опыт говорит о другом.<br><br>Видимо, я опытнее.<br><br>&gt; В cmake всё бывает плохо только в <br>&gt; том случае, когда криворукий разработчик накосячил в CMakeLists.txt.<br>&gt; Увы, за гибкость <br>&gt; инструмента приходится платить возможностью такого. А в автокрапе многое криво by <br>&gt; design. Не говоря о необходимости таскать вместе с исходниками гору нагенерированных <br>&gt; скриптов, объёмом превышающую сам код проекта, причём зачастую &#8212; во много <br>&gt; раз.<br><br>Я не адвокат ни того ни другого. Обе "хороши". И cmake ничуть не лучше.<br><br>&gt;&gt; Латать косяки автокрапа, правда, получается чуть легче (если только авторы весь дебилизм libtool'а не врубают --- в патологических случаях уже только ампутация).<br>&gt; Без libtool в сколько-нибудь сложных проектах не обойтись,<br><br>Сильно неправда.<br><br>&gt; а способов отключить хотя <br>&gt; бы часть его дебилизма я как-то не знаю.<br><br>Иногда он не сильно мешает. Иногда его можно заткнуть.<br>Но встречаются и эпичные сл https://217.65.3.21/openforum/vsluhforumID3/121266.html#51 Fri, 17 Jul 2020 07:51:47 GMT &gt; Когда доходит до чего-то чуть-чуть нетривиального, автокрап и cmake стоят друг друга.<br><br>Мой опыт говорит о другом. В cmake всё бывает плохо только в том случае, когда криворукий разработчик накосячил в CMakeLists.txt. Увы, за гибкость инструмента приходится платить возможностью такого. А в автокрапе многое криво by design. Не говоря о необходимости таскать вместе с исходниками гору нагенерированных скриптов, объёмом превышающую сам код проекта, причём зачастую &#8212; во много раз.<br><br>&gt; Латать косяки автокрапа, правда, получается чуть легче (если только авторы весь дебилизм libtool'а не врубают --- в патологических случаях уже только ампутация).<br><br>Без libtool в сколько-нибудь сложных проектах не обойтись, а способов отключить хотя бы часть его дебилизма я как-то не знаю. В простых же проектах a'la helloworld и голого make хватит.<br> https://217.65.3.21/openforum/vsluhforumID3/121266.html#50 Thu, 16 Jul 2020 21:56:43 GMT "дедушка, вы тоже так говорите". Когда доходит до чего-то чуть-чуть нетривиального,<br>автокрап и cmake стоят друг друга. Концептульная дрянь --- оба. Латать косяки<br>автокрапа, правда, получается чуть легче (если только авторы весь дебилизм libtool'а<br>не врубают --- в патологических случаях уже только ампутация).<br> https://217.65.3.21/openforum/vsluhforumID3/121266.html#49 Thu, 16 Jul 2020 21:11:43 GMT &gt; под amd64, arm64, e2k-4c, i386 и mipsel<br><br>Ой, забыл. Ещё под все архитектуры, поддерживаемые Fedora 3-4 года назад.<br> https://217.65.3.21/openforum/vsluhforumID3/121266.html#48 Thu, 16 Jul 2020 21:02:15 GMT Чтобы запустить go build, и makefile писать не надо.<br>