1.1, Ne01eX (ok), 22:43, 26/02/2018 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
>>Будет прекращена поддержка имени 'configure.in' в качестве входного файла для Autoconf
И вроде бы давно пора. Для своих поделок я configure.ac давно использую. Но вот скрипты сборки других разработчиков придётся перепиливать. И этого ПО много... :-\ Ладно, не смертельно, переживём и это...
| |
1.2, нах (?), 22:47, 26/02/2018 [ответить] [﹢﹢﹢] [ · · · ]
| +3 +/– |
а они стараааательные. В смысле, очень стараются добиться того, чтобы последние ретрограды еще не свалившие на cmake или вовсе на meson, валили поскорей.
| |
|
2.29, X4asd (ok), 14:58, 27/02/2018 [^] [^^] [^^^] [ответить]
| +/– |
> а они стараааательные. В смысле, очень стараются добиться того, чтобы последние ретрограды еще не свалившие на cmake или вовсе на meson, валили поскорей.
скорее стараются чтобы хоть кто-то кроме ретограда -- сделал бы хотябы один новый проект с использованием automake. :-)
количество ретроградов которые через 5 дней не собираются уехать в окончательный пенсионный отдых -- стремительно приближатся к 0..
...так что особо ориентироваться на них не стоит
| |
|
|
2.9, CAE (?), 11:07, 27/02/2018 [^] [^^] [^^^] [ответить]
| +/– |
А альтернатива? mk-configure неплохая идея, но пока маловато по сравнению с autotools. CMake - язык учить, yet another. Scons?
| |
|
3.12, Аноним (-), 13:04, 27/02/2018 [^] [^^] [^^^] [ответить]
| +1 +/– |
> CMake - язык учить
лучше язык, чем неизданный справочник костылей и грабель: http://voices.canonical.com/jussi.pakkanen/2011/09/13/autotools/
cmake кстати не идеален, но сложившая практика использования cmake новых версий приводит к хорошему результату: получается достаточно декларативный скрипт, позволяющий геренировать сборки для мультиплатформ, среди которых актуальные, но неподдерживаемые autotools-ами
| |
|
4.13, Ne01eX (ok), 13:22, 27/02/2018 [^] [^^] [^^^] [ответить]
| +5 +/– |
>> CMake - язык учить
> лучше язык, чем неизданный справочник костылей и грабель: http://voices.canonical.com/jussi.pakkanen/2011/09/13/autotools/
> cmake кстати не идеален, но сложившая практика использования cmake новых версий приводит
> к хорошему результату: получается достаточно декларативный скрипт, позволяющий геренировать
> сборки для мультиплатформ, среди которых актуальные, но неподдерживаемые autotools-ами
Ребя, я щас на полном серЪёзе. Я тут книгу пописываю по тихой сапе про использование gnu make / autoconf+automake / CMake в своих проектах. В равной степени. Потому что считаю, что существующая документация написана какими-то инопланетянами. Это порождает кучу недопонимания, мифов и предубеждений.
Может, в натуре, краудфандинг какой-нибудь организовать? А то я смотрю, многие не совсем догоняют что есть что и как это использовать (в том числе и jussi.pakkanen :-) )...
Есть желающие помочь деньгами?
| |
|
5.14, пох (?), 13:26, 27/02/2018 [^] [^^] [^^^] [ответить]
| –4 +/– |
мне кажется, вы зря тратите время. Это не прочтут, а пока будут читать, оно устареет.
Пишите книгу про meson.
| |
|
6.16, Ne01eX (ok), 13:30, 27/02/2018 [^] [^^] [^^^] [ответить]
| +2 +/– |
> мне кажется, вы зря тратите время. Это не прочтут, а пока будут
> читать, оно устареет.
> Пишите книгу про meson.
meson тоже можно упомянуть, но главная цель - поддержка проектов GNU. А это как раз make / autoconf + automake. CMake идёт прицепом, как альтернатива.
| |
|
7.17, пох (?), 13:54, 27/02/2018 [^] [^^] [^^^] [ответить]
| +/– |
> meson тоже можно упомянуть, но главная цель - поддержка проектов GNU
а смысл? Это ж либо склад раритетов, либо (то немногое что живо вопреки GNU) - перепишут на meson, или еще какую модную ненужно.
В любом случае, чтобы "поддерживать", разбираться в этом необязательно.
Чтобы сделать что-то свое - желательно, но никто не хочет.
Поэтому рождаются бесполезные и бессмысленные монстры, проверяющие миллион ненужных параметров, при том что программа кое-как собирается и работает только в одной-единственной их комбинации.
До сих пор вспоминаю с истерическим смехом свою первую (и, надеюсь, последнюю) встречу с mono, только-только выпущенным в свет. Оно требовало два десятка километровой длины environment variables, потом каким-то нетривиальным способом надо было с ними запустить configure, которая работала минут пять, после чего радостно сообщала, что твоя система не linux и не забыл что еще (какая-то экзотика, чуть ли не hpux) поэтому напиши тут быстренько свою версию вот этих 500 килобайтных исходников (видимо, какой-то middleware) и потом приходи.
Спрашивается - ребята, а зачем вам вообще был при этом autoconf-то нужен? А мы не знаем, так принято. Причем как именно принято - мы тоже не разобрались второпях, поэтому слепили как получилось.
| |
|
8.20, Аноним (-), 14:00, 27/02/2018 [^] [^^] [^^^] [ответить] | +/– | Вот поэтому нужна внятная книга - учитель в виде книги который обучает в каком н... текст свёрнут, показать | |
|
9.22, пох (?), 14:05, 27/02/2018 [^] [^^] [^^^] [ответить] | +/– | да не будут они ее читать, грант уйдет я вроде понял, но автор книги уточнил чт... текст свёрнут, показать | |
|
|
11.25, пох (?), 14:30, 27/02/2018 [^] [^^] [^^^] [ответить] | +/– | стесняюсь спросить - вы читать-то ту что есть - пробовали Ну вот просто info au... текст свёрнут, показать | |
|
|
|
|
7.18, Аноним (-), 13:56, 27/02/2018 [^] [^^] [^^^] [ответить]
| +/– |
> meson тоже можно упомянуть, но главная цель - поддержка проектов GNU. А это как раз make / autoconf + automake. CMake идёт прицепом, как альтернатива.
Поддержка проектов GNU - дело хорошее, вас могут поддержать в том числе и фанаты GNU. CMake, meson, etc - это из серии "пришел-ушел", то есть сегодня одно, завтра - другое.
Советую вам заявить о себе чтобы вас увидела целевая аудитория так чтобы можно видеть хотя бы статус проекта (можете публиковать оглавление и отмечать какие главы уже написаны, а какие в процессе). Мне интересна ваша работа с разных точек зрения, поэтому хотелось бы видеть как продвигаются и обстоят дела. Но обещать я ничего не могу.
| |
7.28, CAE (?), 14:44, 27/02/2018 [^] [^^] [^^^] [ответить]
| +/– |
IMHO если уж брать что-то с чисто декларативным стилем, то mk-configure. Но автор не имеет кучи ресурсов, да и проект слабоизвестный. Но задумка опереться на bsd-style mk - очень здравая, кто под фрёй порты смотрел, тот поймёт о чём я. И язык уже наполовину известен по makefile.
| |
|
6.34, Аноним (-), 22:56, 27/02/2018 [^] [^^] [^^^] [ответить]
| +/– |
> пока будут читать, оно устареет.
> Пишите книгу про meson.
meson устареет ещё до того, как он эту книгу закончит
| |
|
5.30, Аноним (-), 15:21, 27/02/2018 [^] [^^] [^^^] [ответить]
| +/– |
> Я тут книгу пописываю по тихой сапе про использование gnu make / autoconf+automake / CMake в своих проектах. В равной степени. Потому что считаю, что существующая документация написана какими-то инопланетянами.
У GNU make и cmake очень хорошая документация. А autoconf и automake сами написаны инополанетянами, так что их ни документация, ни книги никакие не спасут.
| |
|
4.24, CAE (?), 14:18, 27/02/2018 [^] [^^] [^^^] [ответить]
| +/– |
>> CMake - язык учить
> лучше язык, чем неизданный справочник костылей и грабель: http://voices.canonical.com/jussi.pakkanen/2011/09/13/autotools/
Статья отличная. У самого полно проблем с простейшим повторным запуском одного макроса :) И где документировано, что для второго запуска его лучше обернуть в shell function - бог весть. Autotools - адище, только старый опыт с sendmail+m4 и позволяет как-то жить.
| |
|
5.26, пох (?), 14:34, 27/02/2018 [^] [^^] [^^^] [ответить]
| +/– |
> в shell function - бог весть. Autotools - адище, только старый
> опыт с sendmail+m4 и позволяет как-то жить.
ну вот по-моему выучить относительно универсальный (пусть и нигде нынче неиспользуемый) m4 (хотя бы на уровне правил расстановки кавычек) и запомнить где посмотреть два десятка макросов - гораздо правильней, чем учить мертворожденный язык cmake.
но это если вообще есть зачем его учить. Я в этом последнее время сильно не уверен.
| |
|
6.31, Аноним (-), 15:57, 27/02/2018 [^] [^^] [^^^] [ответить]
| –3 +/– |
> учить мертворожденный язык cmake
Иди проспись. Такой мертворожденности только позавидовать. А учить там особо и нечего, сам язык исключительно примитивен (в отличие от набора команд и переменных, но с ними всё же многократно приятнее иметь дело, чем с макросами автокрэпа).
| |
6.37, yet another anonymous (?), 12:15, 28/02/2018 [^] [^^] [^^^] [ответить]
| +/– |
>> в shell function - бог весть. Autotools - адище, только старый
>> опыт с sendmail+m4 и позволяет как-то жить.
> ну вот по-моему выучить относительно универсальный (пусть и нигде нынче неиспользуемый)
> m4 (хотя бы на уровне правил расстановки кавычек) и запомнить где
> посмотреть два десятка макросов - гораздо правильней, чем учить мертворожденный язык
> cmake.
В autotools проблема ни разу не в m4. Разбирать макросы в том объёме --- малопродуктивное занятие. А набор/поведение макросов меняется в каждой версии autocraps. В чём цель-то была?
> но это если вообще есть зачем его учить. Я в этом последнее
> время сильно не уверен. | |
|
|
|
3.40, Аноним (-), 15:17, 28/02/2018 [^] [^^] [^^^] [ответить]
| +/– |
> CMake - язык учить, yet another
Это глупейшая претензия, так как у каждой уважающей утилиты есть свой язык в том или ином виде, начиная с конфига. Потому что язык заточенный под конкретную цель всегда лаконичнее и удобнее чем что-то-общего-назначения. А так у cmake простой и чистый синтаксис.
> Scons?
Даже близко не подходи. Это даже не система сборки, это фреймворк чуть-чуть помогающий в написании системы сборки, в результате которого появляется монструозные скрипты на питоне сравнимые по нечитабельности с configure, причём вместо унификации каждый из них велосипедит свой способ обработки аргументов, флагов, поиска зависимостей и т.д. Ещё и с переходом на 3 питон будут проблемы.
| |
|
|
|
2.7, Led (ok), 01:18, 27/02/2018 [^] [^^] [^^^] [ответить]
| –1 +/– |
> Ну зачем они это делают?
Чтоб у хипстеров подгорало.
| |
2.8, пох (?), 09:52, 27/02/2018 [^] [^^] [^^^] [ответить]
| –1 +/– |
ну такие вот нынче пошли "разработчики". Другие вымерли или подались в эффективные менеджеры.
завязать пакет утилит для разработки _переносимых_ программ исключительно на gnu rm - как мило...
Впрочем, предлагаю расслабиться. Последней попадавшей мне под руку программой, использующей configure по назначению, был php5. (он же - и работает в том числе на крайне экзотических системах)
Умение писать не linux-only программы утрачено обезьянками напрочь, если современный софт и собирается под чем-то другим, то потому, что авторы чего-то другого потратили неимоверные усилия на багосовместимость именно с линуксом. autoconf сто лет уже как всеми используется не для переносимости, а потому, что умение написать собственный шелл-скрипт с аж пятью возможными опциями конфигурации - тоже утрачено нафиг, как и умение писать мэйкфайлы.
А если, не дай Б-же, кто-то пишет, то получается ад, трэш и п-ц, как у мозилы, требующей стопиццот питоновских модулей и сэндбоксинга, а потом...тадам, запускающей все тот же configure, потому что разобраться, как оно работало до них, тоже ниасилили.
Поэтому безумный миллион autoconf'овых проверок жрет ресурсы планеты совершенно зря - результат все равно способен работать только на одной-единственной платформе.
| |
|
3.11, user (??), 12:26, 27/02/2018 [^] [^^] [^^^] [ответить]
| +1 +/– |
>рассчитаны на использование утилиты "rm", соответствующей требованиям следующей версии стандарта POSIX
>завязать пакет утилит для разработки _переносимых_ программ исключительно на gnu rm
У кого-то проблемы со зрением.
| |
|
4.19, пох (?), 14:00, 27/02/2018 [^] [^^] [^^^] [ответить]
| –1 +/– |
>>рассчитаны на использование утилиты "rm", соответствующей требованиям следующей версии стандарта POSIX
>>завязать пакет утилит для разработки _переносимых_ программ исключительно на gnu rm
> У кого-то проблемы со зрением.
у кого-то проблемы с пониманием. Требование соответствия еще недонаписанному стандарту POSIX, на которые все давно уже наплевали, это просто завуалированное "мы ничего кроме линуксных fileutils ниасилили и асиливать не хотим, такой у нас афигенный автоматический генератор *портабильного* кода". С линукса на линукс, и только наираспоследней версии, обпортируйтесь.
это ж гораздо проще, чем головой думать.
| |
|
5.32, Аноним (-), 16:00, 27/02/2018 [^] [^^] [^^^] [ответить]
| +/– |
> у кого-то проблемы с пониманием. Требование соответствия еще недонаписанному стандарту
> POSIX, на которые все давно уже наплевали, это просто завуалированное "мы
> ничего кроме линуксных fileutils ниасилили и асиливать не хотим, такой у
> нас афигенный автоматический генератор *портабильного* кода".
Ты давно видел какую-нибудь реализацию rm, которая с опцией -f возвращает статус, отличный от 0? Скажи, где такую найти, мне интересно посмотреть.
| |
|
6.33, пох (?), 18:08, 27/02/2018 [^] [^^] [^^^] [ответить]
| –1 +/– |
> Ты давно видел какую-нибудь реализацию rm, которая с опцией -f возвращает статус, отличный от 0?
довольно давно, но уверен, она там вполне себе и осталась, лежит себе в bin ;-) (хепе, да. Оно еще и -rf / умело, не то что нынешние)
А вот та, которая 0, полагаю, наличествует ровно в линуксе и *bsd (где вынуждены копировать все причуды). Даже за современную солярку не вполне уверен.
А теперь возвращаемся к исходному вопросу: зачем вам сложная и не очень современная система автоматического учета особенностей платформы, если она работает только на линуксе и еще шаг-полтора в сторону, где именно линукс и вынуждены копировать, даже если не хотят?
Если вы хотите этим признать, что кроме линуксов разного сорта и их эмуляций ничего и не осталось - ок, а система-то тогда - зачем?
| |
|
5.39, yet another anonymous (?), 13:37, 28/02/2018 [^] [^^] [^^^] [ответить]
| +/– |
> "мы
> ничего кроме линуксных fileutils ниасилили и асиливать не хотим, такой у
> нас афигенный автоматический генератор *портабильного* кода". С линукса на линукс, и
> только наираспоследней версии, обпортируйтесь.
Автоматический генератор *портабельного кода*, говорите? Ну-ну. McNealy что-то уже приносил с похожими словами.
| |
|
|
3.38, yet another anonymous (?), 13:29, 28/02/2018 [^] [^^] [^^^] [ответить]
| +/– |
> Поэтому безумный миллион autoconf'овых проверок жрет ресурсы планеты совершенно зря - результат все равно способен работать только на одной-единственной платформе.
Это таки да, но в этом оно мало отличается и от CMake/SCons/meson.
О вариациях для разных платформ все равно должен заботиться автор, а проверки на тему HAVE_UNISTD_H практически бессмысленны.
| |
|
|
1.10, Аноним (-), 11:23, 27/02/2018 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
С удалением поддержки DOS они погорячились, ведь есть же FreeDOS и он жив.
| |
|
2.15, Ne01eX (ok), 13:26, 27/02/2018 [^] [^^] [^^^] [ответить]
| +/– |
> С удалением поддержки DOS они погорячились, ведь есть же FreeDOS и он
> жив.
FreDOS не использует automake
| |
2.21, пох (?), 14:01, 27/02/2018 [^] [^^] [^^^] [ответить]
| –1 +/– |
> С удалением поддержки DOS они погорячились, ведь есть же FreeDOS и он
> жив.
и много вы знаете проектов программ под freedos, использующих autoconf? А _новых_, которым вот уперлось использовать самую последнюю версию?
imho, под windows ME их и то могло бы быть больше (в смысле, чисто по недоразумению, что-нибудь еще не только собирается, но и работает)
| |
|
1.35, Аноним (-), 03:30, 28/02/2018 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Вообще это гонение в системах сборки достало уже.
Так было хорошо, что тут не нужен был питон.
Но нет начали всобачивать meson с нинзей.
Ну ладно бы как опция, но на "некоторых" проектах это стало безальтернативно.
С относительно недавних пор на своих проектах начал вплотную использовать чистый Makefile без всяких генерилок. Работать стало приятнее, не надо думать что опять кто-нибудь где-нибудь что-то сломает. Вначале нужно немного больше подумать о том как собирать проект, но оно того стоит. Значительное время использовал cmake. Но то как редхатовцы его последнее время его заворачивают и как он (cmake) генерирует маны заставило меня задуматься нужен ли он мне вообще?!
А так для более сложных вещей automake и autoconf самое то.
| |
|