Вариант для распечатки		Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Изначальное сообщение		[ Отслеживать ]

"Доступен GNU Autoconf 2.70 "	+/–
Сообщение от opennews (??), 09-Дек-20, 12:41
После восьми лет с момента публикации версии 2.69 представлен выпуск  пакета GNU Autoconf 2.70, в котором поставляется набор M4-макросов для создания скриптов автоконфигурации для сборки приложений в различных Unix-подобных системах (на основе подготовленного шаблона выполняется генерация скрипта "configure")... Подробнее: https://www.opennet.me/opennews/art.shtml?num=54226
Ответить | Правка | Cообщить модератору

Сообщения

[Сортировка по ответам | RSS]

3. Сообщение от little Bobby tables (?), 09-Дек-20, 12:50	+8 +/–
старый, добрый, ламповый автоконф. Но и на солнце есть пятна, например можно было в config.log указывать строчку, где именно описывается вызов непрошедшего теста. Сэкономило б чутка времени при анализе окружения.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #17

4. Сообщение от lockywolf (ok), 09-Дек-20, 12:57	+1 +/–
Надеюсь, теперь книга John Calcote выйдет поскорее!
Ответить | Правка | Наверх | Cообщить модератору

5. Сообщение от mikhailnov (ok), 09-Дек-20, 13:10	–1 +/–
Автокрап сила
Ответить | Правка | Наверх | Cообщить модератору

6. Сообщение от Аноним (6), 09-Дек-20, 13:29	+4 +/–
>Обеспечена совместимость с выпущенными в 2011 году стандартами C и C++. Не прошло и 10 лет!!!
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #11

7. Сообщение от Zenitur (ok), 09-Дек-20, 13:44	–1 +/–
Помню, когда прекратилась поддержка CentOS 5, в Firefox сразу перешли на GTK3 и PulseAudio. Сейчас, когда прекратилась поддержка CentOS 6, Autoconf 2.70 вышел. Эх, а ведь 2.69 это целая эпоха.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #9

8. Сообщение от Аноним (20), 09-Дек-20, 13:57	+/–
> Обеспечена совместимость с выпущенными в 2011 году стандартами C и C++. Сверил календарь.
Ответить | Правка | Наверх | Cообщить модератору

9. Сообщение от Аноним (9), 09-Дек-20, 14:08	+9 +/–
Сейчас, когда прекратилась поддержка CentOS вообще. https://www.opennet.me/opennews/art.shtml?num=54219
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #7 Ответы: #27

10. Сообщение от Аноним (10), 09-Дек-20, 14:24	–8 +/–
Закопайте вы уже это. Самый большой позор гну/линукса. Есть божественный meson от RedHat.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #12, #28

11. Сообщение от Аноним (11), 09-Дек-20, 14:25	+8 +/–
Всё суетитесь?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #6

12. Сообщение от Урри (ok), 09-Дек-20, 14:32	+6 +/–
Толстовато.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #10 Ответы: #13, #15

13. Сообщение от Аноним (10), 09-Дек-20, 15:13	–3 +/–
что толстовато? Никто в 2020 не хочет копаться в этом макроболоте.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #12 Ответы: #14, #21

14. Сообщение от Аноним (14), 09-Дек-20, 15:29	+2 +/–
> Никто в 2020 не хочет копаться в этом макроболоте Именно по-этому сверху накинули невнятный cmake и уродский json ? Уж лучше божественный autotools чем все эти портянки
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #13 Ответы: #16, #24

15. Сообщение от Аноним (-), 09-Дек-20, 15:30	+1 +/–
Ога, я тоже это заметил.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #12

16. Сообщение от Аноним (16), 09-Дек-20, 15:50	–1 +/–
json это не система сборки, а формат данных. Выучи хотя бы это.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #14

17. Сообщение от Аноним (17), 09-Дек-20, 16:06	–8 +/–
Кто хотел сэкономить время, те уже давно пользуются вменяемыми билд-системами, с которыми не надо продираться через три слоя автогенерированных скриптов под шеллы семидесятого года.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #3 Ответы: #18, #26

18. Сообщение от пох. (?), 09-Дек-20, 16:57	+2 +/–
> Кто хотел сэкономить время, те уже давно пользуются вменяемыми билд-системами а что "вменяемые" работают только под "новым стандартом" - так это неважно, код этих экономных тоже только в нем и работает, причем только с еще недонаписанными распоследними версиями ВСЕГО. В целом, согласен, зачем бы им автоконф? > с которыми не надо продираться через три слоя автогенерированных скриптов под шеллы > семидесятого года. через них не надо "продираться", они просто делают свою работу. При условии что ты умеешь делать свою. autoconf это немного не про твое неумение писать мэйкфайлы, это про портируемый софт, который вы теперь писать разучились.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #17 Ответы: #19, #20, #23, #35

19. Сообщение от Самый Лучший Гусь (?), 09-Дек-20, 17:23	–4 +/–
> портируемый софт Так ничего, кроме GNU/Linux не осталось.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #18 Ответы: #22, #30, #33, #76

20. Сообщение от Аноним (20), 09-Дек-20, 17:37	–1 +/–
> через них не надо "продираться", они просто делают свою работу. При условии что ты умеешь делать свою. Хреново делают только. Особенно если у тебя пачка библиотек, и приходится иметь дело с libtool. Там вообще тушите свет, сливайте воду.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #18

21. Сообщение от Аноним (20), 09-Дек-20, 17:40	+1 +/–
Толстовато предлагать заменить его питоноболотом.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #13 Ответы: #25

22. Сообщение от Аноним (22), 09-Дек-20, 17:42	+1 +/–
С такими желаниями вокруг тебя скоро никого, кроме альтернативно ориентированных, не останется.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #19

23. Сообщение от Аноним (23), 09-Дек-20, 18:32	+1 +/–
Чем вам CMake непортируемый?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #18 Ответы: #36, #37, #55, #73

24. Сообщение от Аноним (23), 09-Дек-20, 18:33	–1 +/–
Где ты нашёл "уродский json"?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #14

25. Сообщение от Аноним (85), 09-Дек-20, 18:47	–1 +/–
meson не имеет никакого отношения к питону, кроме того, что эталонная реализация на нём написана. Если она лично вас не устраивает, напишите свою на любимом русте, или хоть на си, только фракталу потом не показывайте.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #21 Ответы: #29

26. Сообщение от Аноним (-), 09-Дек-20, 19:01	+/–
> уже давно пользуются вменяемыми билд-системами, с которыми не надо продираться > через три слоя автогенерированных скриптов под шеллы семидесятого года. Да, там три слоя фекалий другого типа хомячков, а когда что-то ломается то вообще логов нет. Не говоря о том что build-deps более другие. В сабже configure по минимуму вообще послать может на системе с posix shell и более нифига. И это уже начало.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #17 Ответы: #47, #54

27. Сообщение от Аноним (-), 09-Дек-20, 19:01	–1 +/–
Ну, как раз вовремя же. Пусть теперь шляпа сама это и опакечивает, если ей надо.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #9

28. Сообщение от Аноним (-), 09-Дек-20, 19:03	+3 +/–
> Есть божественный meson от RedHat. 1) Не от редхат а от каких-то левых уродов, к тому же откровенно коммерческих. 2) Эти уроды к тому же крайнее недружелюбны и генерить мэйкфайлы в принципе не намерены. Вот что у этих кондомов точно не отнять так это комплекс богов, пихающих свое счастье в глотку лопатой.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #10

29. Сообщение от Аноним (-), 09-Дек-20, 19:04	+1 +/–
Так других то и нет. И синтаксис DSL пихоноуродский. Cmake и то приятнее этого шита. И он хотя-бы makefiles генерить мне умеет, а не требует поставить каких-то там нинзя или еще какую неведому фигню.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #25

30. Сообщение от пох. (?), 09-Дек-20, 19:26	–1 +/–
дык, я и говорю - нах он не нужен тот автоконф. Ты еще забыл уточнить,конечно, что кроме (по тексту) самых наираспоследних версий, а кто не спрятался - сам виноват. А то можно посмотреть, к примеру, _правильное_ применение gnu autoconf в не то что linux-only, а при сборке драйвера ядра - ага, ZoL. Но это совершенно неправильный, конечно, драйвер - "с 2.6.32 по 5.+", кто ж так пишет, кроме полных лохов-неудачников?! А 99% реальных применений автоконфа - --with-ненужно или --enable-ненужно. Где автоконф тоже ненужно, совершенно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #19

31. Сообщение от anonymous (??), 09-Дек-20, 20:11	–2 +/–
Лично я считаю, что должна быть сквозная интеграция от сборщика до дистрибутива. Единый софт должен собирать софт, клепать артефакты, паковать их в пакеты дистрибутива и накатывать куда скажут. Чтобы любые зависимостей на всей длине цепочек могли решаться системно. Чтобы цикл от пуша до тестирования (как софта самого по себе так и пакета в целом) до публикации был как можно корче и безболезненнее.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #34

32. Сообщение от Козлетто (?), 09-Дек-20, 20:12	+/–
Вот они настоящие ценности! Не то что ваши meson'ы, c{q}make и прочие нинзя
Ответить | Правка | Наверх | Cообщить модератору

33. Сообщение от заминированный тапок (ok), 09-Дек-20, 20:19	–1 +/–
> Так ничего, кроме GNU/Linux не осталось. так кроме GNU/Linux ничего не нужно. а под портируемостью подразумевается поддержка разных аппаратных архитектур, а ненужных ОСей
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #19 Ответы: #44

34. Сообщение от Led (ok), 09-Дек-20, 22:48	+6 +/–
...и всё это при том, чтоб в школу не ходить, уроки не учить, а весь день смотреть мультики и прочие тиктоки...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #31

35. Сообщение от topin89 (ok), 09-Дек-20, 23:17	+2 +/–
Всё это замечательно, но на практике с autoconf было сушественно больше мороки, чем с CMake. > а что "вменяемые" работают только под "новым стандартом" - так это неважно, код этих экономных тоже только в нем и работает, причем только с еще недонаписанными распоследними версиями ВСЕГО. Ну внезапно, если есть возможность пользоваться последними стандартами -- ими и пользуются. Да и то, большинство библиотек работает на предыдущем стандарте, или стандарте на два поколения назад, для той самой совместимости. Или поддерживает оба стандарта, но старый в ограниченном режиме > через них не надо "продираться", они просто делают свою работу. При условии что ты умеешь делать свою. Конфиги автоконфа write-only что-ли? > autoconf это немного не про твое неумение писать мэйкфайлы, это про портируемый софт, который вы теперь писать разучились. Да как сказать, на CMake портируемый на Винду софт попроще писать получается. Да и под Андроид тоже. Да и вообще, autoconf так себе система конфигурации, лучшее в ней то, что она была одной из первых. Если не поставил gettext какой-нибудь -- падает с ошибкой, по которой никак не понять, что происходит. Если это такой стандартный инструмент, что не требует проверки на наличие, какого хрена его нет в зависимостях? В CMake всё в комплекте, а что нет, как правило ищется через find_package и если не находится, хотя бы ясно, чего не хватает. Да и вообще, autoconf скрипт, который умеет делать autoreconf не в папке с кодом -- это редкость. Блин, да банально сделать configure, способным собирать вне папки с кодом не у всех выходит. И думай потом, где нагенерено, а где реальный код. Я видел только одно преимущество -- генерация хелпа для ./configure. Вроде как такое можно сделать и для CMakeLists.txt, но на практике пока не встречал
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #18 Ответы: #38, #50, #53, #56

36. Сообщение от slepnoga (ok), 10-Дек-20, 01:08	+1 +/–
Тем, что он, внизапна, требует компиляции. ldd /usr/bin/cmake         linux-vdso.so.1 (0x00007fffa5586000)         libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fe20b7b7000)         libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007fe20b79b000)         libarchive.so.13 => /usr/lib/x86_64-linux-gnu/libarchive.so.13 (0x00007fe20b6d9000)         libcurl.so.4 => /usr/lib/x86_64-linux-gnu/libcurl.so.4 (0x00007fe20b648000)         libjsoncpp.so.1 => /usr/lib/x86_64-linux-gnu/libjsoncpp.so.1 (0x00007fe20b612000)         libuv.so.1 => /usr/lib/x86_64-linux-gnu/libuv.so.1 (0x00007fe20b5e1000)         librhash.so.0 => /usr/lib/x86_64-linux-gnu/librhash.so.0 (0x00007fe20b5ae000)         libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fe20b58b000)         libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007fe20b3aa000)         libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fe20b25b000)         libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007fe20b240000)         libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fe20b04e000)         /lib64/ld-linux-x86-64.so.2 (0x00007fe20bda2000)         libnettle.so.7 => /usr/lib/x86_64-linux-gnu/libnettle.so.7 (0x00007fe20b012000)         libacl.so.1 => /usr/lib/x86_64-linux-gnu/libacl.so.1 (0x00007fe20b007000)         liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x00007fe20afde000)         libzstd.so.1 => /usr/lib/x86_64-linux-gnu/libzstd.so.1 (0x00007fe20af35000)         liblz4.so.1 => /usr/lib/x86_64-linux-gnu/liblz4.so.1 (0x00007fe20af14000)         libbz2.so.1.0 => /lib/x86_64-linux-gnu/libbz2.so.1.0 (0x00007fe20af01000)         libxml2.so.2 => /usr/lib/x86_64-linux-gnu/libxml2.so.2 (0x00007fe20ad45000)         libnghttp2.so.14 => /usr/lib/x86_64-linux-gnu/libnghttp2.so.14 (0x00007fe20ad1c000)         libidn2.so.0 => /usr/lib/x86_64-linux-gnu/libidn2.so.0 (0x00007fe20acfb000)         librtmp.so.1 => /usr/lib/x86_64-linux-gnu/librtmp.so.1 (0x00007fe20acdb000)         libssh.so.4 => /usr/lib/x86_64-linux-gnu/libssh.so.4 (0x00007fe20ac6d000)         libpsl.so.5 => /usr/lib/x86_64-linux-gnu/libpsl.so.5 (0x00007fe20ac5a000)         libssl.so.1.1 => /usr/lib/x86_64-linux-gnu/libssl.so.1.1 (0x00007fe20abc5000)         libcrypto.so.1.1 => /usr/lib/x86_64-linux-gnu/libcrypto.so.1.1 (0x00007fe20a8ef000)         libgssapi_krb5.so.2 => /usr/lib/x86_64-linux-gnu/libgssapi_krb5.so.2 (0x00007fe20a8a2000)         libldap_r-2.4.so.2 => /usr/lib/x86_64-linux-gnu/libldap_r-2.4.so.2 (0x00007fe20a84c000)         liblber-2.4.so.2 => /usr/lib/x86_64-linux-gnu/liblber-2.4.so.2 (0x00007fe20a83b000)         libbrotlidec.so.1 => /usr/lib/x86_64-linux-gnu/libbrotlidec.so.1 (0x00007fe20a82d000)         libicuuc.so.66 => /usr/lib/x86_64-linux-gnu/libicuuc.so.66 (0x00007fe20a645000)         libunistring.so.2 => /usr/lib/x86_64-linux-gnu/libunistring.so.2 (0x00007fe20a4c3000)         libgnutls.so.30 => /usr/lib/x86_64-linux-gnu/libgnutls.so.30 (0x00007fe20a2ed000)         libhogweed.so.5 => /usr/lib/x86_64-linux-gnu/libhogweed.so.5 (0x00007fe20a2b5000)         libgmp.so.10 => /usr/lib/x86_64-linux-gnu/libgmp.so.10 (0x00007fe20a231000)         libkrb5.so.3 => /usr/lib/x86_64-linux-gnu/libkrb5.so.3 (0x00007fe20a152000)         libk5crypto.so.3 => /usr/lib/x86_64-linux-gnu/libk5crypto.so.3 (0x00007fe20a121000)         libcom_err.so.2 => /lib/x86_64-linux-gnu/libcom_err.so.2 (0x00007fe20a11a000)         libkrb5support.so.0 => /usr/lib/x86_64-linux-gnu/libkrb5support.so.0 (0x00007fe20a10b000)         libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2 (0x00007fe20a0ef000)         libsasl2.so.2 => /usr/lib/x86_64-linux-gnu/libsasl2.so.2 (0x00007fe20a0d2000)         libgssapi.so.3 => /usr/lib/x86_64-linux-gnu/libgssapi.so.3 (0x00007fe20a08b000)         libbrotlicommon.so.1 => /usr/lib/x86_64-linux-gnu/libbrotlicommon.so.1 (0x00007fe20a068000)         libicudata.so.66 => /usr/lib/x86_64-linux-gnu/libicudata.so.66 (0x00007fe2085a7000)         libp11-kit.so.0 => /usr/lib/x86_64-linux-gnu/libp11-kit.so.0 (0x00007fe208471000)         libtasn1.so.6 => /usr/lib/x86_64-linux-gnu/libtasn1.so.6 (0x00007fe20845b000)         libkeyutils.so.1 => /lib/x86_64-linux-gnu/libkeyutils.so.1 (0x00007fe208452000)         libheimntlm.so.0 => /usr/lib/x86_64-linux-gnu/libheimntlm.so.0 (0x00007fe208446000)         libkrb5.so.26 => /usr/lib/x86_64-linux-gnu/libkrb5.so.26 (0x00007fe2083b3000)         libasn1.so.8 => /usr/lib/x86_64-linux-gnu/libasn1.so.8 (0x00007fe20830c000)         libhcrypto.so.4 => /usr/lib/x86_64-linux-gnu/libhcrypto.so.4 (0x00007fe2082d4000)         libroken.so.18 => /usr/lib/x86_64-linux-gnu/libroken.so.18 (0x00007fe2082b9000)         libffi.so.7 => /usr/lib/x86_64-linux-gnu/libffi.so.7 (0x00007fe2082ad000)         libwind.so.0 => /usr/lib/x86_64-linux-gnu/libwind.so.0 (0x00007fe208283000)         libheimbase.so.1 => /usr/lib/x86_64-linux-gnu/libheimbase.so.1 (0x00007fe208271000)         libhx509.so.5 => /usr/lib/x86_64-linux-gnu/libhx509.so.5 (0x00007fe208223000)         libsqlite3.so.0 => /usr/lib/x86_64-linux-gnu/libsqlite3.so.0 (0x00007fe2080fa000)         libcrypt.so.1 => /lib/x86_64-linux-gnu/libcrypt.so.1 (0x00007fe2080bd00 ахринеть, да ))) И это не говоря про отсутствие жесткого триплета при конфигурировании - никогда не знаешь, есть ли автозависимости, и если есть, откуда оно их цепануло
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #23 Ответы: #39, #43, #51, #85

37. Сообщение от slepnoga (ok), 10-Дек-20, 01:10	+/–
head -1 /usr/bin/autoconf #! /bin/sh такие дела, да: из депенсов по __максимуму__ sh, perl, m4
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #23 Ответы: #45, #52

38. Сообщение от slepnoga (ok), 10-Дек-20, 01:12	+/–
>стандартный инструмент, что не требует проверки на наличие, Хоспади, ну собирайте своих котиков, плееры и мордокниги чем хотите - все равно bootstrap нового arch'a  не для смузихлебов
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #35 Ответы: #42

39. Сообщение от Ordu (ok), 10-Дек-20, 07:47	–1 +/–
> Тем, что он, внизапна, требует компиляции. И как это влияет на портируемость? > ахринеть, да ))) Что-то я не вижу в зависимостях ничего непортируемого.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #36 Ответы: #46

40. Сообщение от Аноним (40), 10-Дек-20, 09:13	+/–
> Добавлена поддержка повторяемых сборок, результат которых будет одинаковым на разных системах. Reproduction на 100% решалось устоновкой переменной среды и добавлением нескольких опций к gcc. Не удивлюсь если работавшую как швейцарские часики reproduction (одно из требований безопасности) сегодня сломали.
Ответить | Правка | Наверх | Cообщить модератору

41. Сообщение от Аноним (41), 10-Дек-20, 09:18	+/–
Вирусогенерялка: https://www.opennet.me/openforum/vsluhforumID9/10331.html
Ответить | Правка | Наверх | Cообщить модератору

42. Сообщение от topin89 (ok), 10-Дек-20, 10:59	+/–
>>стандартный инструмент, что не требует проверки на наличие, > Хоспади, ну собирайте своих котиков, плееры и мордокниги чем хотите - все > равно bootstrap нового arch'a  не для смузихлебов А по существу можно? А главное, что за дихотомия такая? Если инструмент сложный -- то это тру, если проще с той же функциональностью, но новее -- то сразу для смузихлёбов. Так можно что угодно объявить ненужным, даже C (Есть же B или асм). Да и не такой уж CMake и новый, 20 лет уже.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #38 Ответы: #60

43. Сообщение от topin89 (ok), 10-Дек-20, 11:02	–2 +/–
> И это не говоря про отсутствие жесткого триплета при конфигурировании - никогда > не знаешь, есть ли автозависимости, и если есть, откуда оно их > цепануло Можно подетальнее. Я не знаю, что значит "жесткий триплет при конфигурировании" и на что это влияет.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #36 Ответы: #64

44. Сообщение от пох. (?), 10-Дек-20, 12:35	–1 +/–
> а под портируемостью подразумевается поддержка разных аппаратных архитектур, Угу, угу - обоих двух - amd64 и aarch64. Мозги при этом включать вообще не понадобится. Вон, берите пример с "мультиплатформенной" системы лохот...электрон! (а то ж можно додуматься, что на какой-нибудь платформе твоих любимых готовых библиотечек - опаньки, а вообще ж нет. И не предвидится. Да ты ж модный пацан, не то что некоторые лохи, умеющие и в такое - нет, так заменим менее эффективным своим кодом, зато кроссплатформенным - ты просто скажешь "фуфуфу, фуфло ваша платформа, купите мак, как у всех!") Хорошо бы в код еще пометочку какую сразу ставить, чтоб отличать подобные поделки от нормального софта с первого взгляда. А, ну да, ну да - уже ж поставлено. Использует не autotools и не самодельную им замену, написанную из разумных соображений - в помойку.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #33 Ответы: #48

45. Сообщение от пох. (?), 10-Дек-20, 12:36	+/–
самое главное что для _сборки_ проекта (в том числе и модифицированного по месту) они _вообще_ не нужны. Нужен только примерно баш-совместимый шелл.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #37

46. Сообщение от пох. (?), 10-Дек-20, 12:38	+4 +/–
> И как это влияет на портируемость? они реально такие т*пые :-( > Что-то я не вижу в зависимостях ничего непортируемого. Приступай к портированию. Вот как ВЕСЬ этот мусор спортируешь на какую-нибудь необычную платформу - сможешь начать портировать собственно свой хеловрот из трех строк, который без него не собирается, потому что ты не умеешь в мэйкфайлы.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #39 Ответы: #49, #77

47. Сообщение от пох. (?), 10-Дек-20, 12:39	+/–
А зачем тебе их логи? Когда что-то сломается в модном мезоне или еще какой ереси - ты вряд ли сможешь это починить.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #26

48. Сообщение от заминированный тапок (ok), 10-Дек-20, 12:54	+/–
>[оверквотинг удален] > (а то ж можно додуматься, что на какой-нибудь платформе твоих любимых готовых > библиотечек - опаньки, а вообще ж нет. И не предвидится. Да > ты ж модный пацан, не то что некоторые лохи, умеющие и > в такое - нет, так заменим менее эффективным своим кодом, зато > кроссплатформенным - ты просто скажешь "фуфуфу, фуфло ваша платформа, купите мак, > как у всех!") > Хорошо бы в код еще пометочку какую сразу ставить, чтоб отличать подобные > поделки от нормального софта с первого взгляда. А, ну да, ну > да - уже ж поставлено. Использует не autotools и не самодельную > им замену, написанную из разумных соображений - в помойку. чё за х*ню я только что прочитал? О_О какой-то текстовый артхаус
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #44

49. Сообщение от Ordu (ok), 10-Дек-20, 13:02	–1 +/–
> Вот как ВЕСЬ этот мусор спортируешь на какую-нибудь необычную платформу Что это за платформа, куда весь этот "мусор" ещё не спортировали? Кому она сдалась такая? Что там делать вообще на этой платформе? Ядро-то туда "спортировали"? Платформа без софта -- это не платформа, а кусок железа. Чтобы сделать из неё платформу надо поработать руками. > сможешь начать портировать собственно свой хеловрот из трех строк, который без него не собирается, потому что ты не умеешь в мэйкфайлы. пох, ну сколько можно кривляться? Все вокруг тебя не осилили bash, make, бла-бла-бла... Что там осиливать? Не, ну ты сам-то осилил? И чо-как, неужели так сложно было, что теперь ты считаешь, что тебе есть чем гордиться?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #46 Ответы: #62

50. Сообщение от пох. (?), 10-Дек-20, 15:30	+2 +/–
> Конфиги автоконфа write-only что-ли? в целом да - написал один раз и забыл. Как оно и должно было быть. > Да как сказать, на CMake портируемый на Винду софт попроще писать получается. Не, не попроще. Потому что его писать приходится. Что с cmake, что без cmake. Я, если что, пытался тут. Нихрена cmake за меня не написал, представь себе! И я изрядно не рад был выяснять, как в нем вручную обойти проблему нетипичных зависимостей (вместо того чтоб возиться с сишным кодом, ради которого все затевалось) - и, честно говоря, голый мэйкфайл я бы для такого проекта быстрее написал. Ну а что ms всосала cmake со всеми нужными деталями прямо в visual c, так что модному-современному "разработчику" вообще надо ответить на вопрос "откуда git clone" и оно все волшебным образом ему соберется - ну так ей тоже хотелось как попроще, а не чтоб ты мог писать переносимый код. Винда и новыйстандарт, и хватит всем. > Если это такой стандартный инструмент, что не требует проверки на наличие, какого хрена его > нет в зависимостях? вопрос к майнтейнеру твоего дистрибутива. Зависимости ему полагалось бы написать. > В CMake всё в комплекте собранном тебе MS. А что не в комплекте - то не работает. Вообще, чтоб ты в курсе был, у cmake есть свои стопиццот опций сборки. Правда, большую часть их трогать нельзя, потому что соберется, но собрать ничего не сможет. Забавно, что пара из них порождала циклические зависимости.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #35

51. Сообщение от Аноним (20), 10-Дек-20, 19:51	+/–
> И это не говоря про отсутствие жесткого триплета при конфигурировании - никогда не знаешь, есть ли автозависимости, и если есть, откуда оно их цепануло Триплет ему подавай… Тулчейн определи как доке описано, и не будет ничего цеплять откуда не надо.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #36 Ответы: #58

52. Сообщение от Аноним (20), 10-Дек-20, 19:52	+/–
> из депенсов по __максимуму__ > sh, perl, m4 Perl-то ты где там нашёл?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #37 Ответы: #57

53. Сообщение от Аноним (20), 10-Дек-20, 19:58	+/–
> Я видел только одно преимущество -- генерация хелпа для ./configure. Вроде как такое можно сделать и для CMakeLists.txt, но на практике пока не встречал В смысле? В option() в обязательном порядке прописывается строка справки. Выводится по cmake -LH.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #35 Ответы: #59

54. Сообщение от Аноним (20), 10-Дек-20, 20:01	+1 +/–
> Да, там три слоя фекалий другого типа хомячков, а когда что-то ломается то вообще логов нет. Ну не обязательно же речь о meson, чего ты?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #26

55. Сообщение от Аноним (64), 10-Дек-20, 20:58	–1 +/–
> Чем вам CMake непортируемый? Не портируемый он тем, что он никогда не умел и всё ещё не умеет определять какие флаги нужны сишному компилятору на HP-UX и на AIX для безопасного использования потоков. По сути, он ничего кроме gcc -pthread и не знает. Модуль FindThreads.cmake - никчёмная ерунда.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #23

56. Сообщение от Аноним (64), 10-Дек-20, 21:08	+/–
> Всё это замечательно, но на практике с autoconf было сушественно больше мороки, чем с CMake. В моей практике с cmake-ом было СУЩЕСТВЕННО больше мороки на UNIX-ах, чем с autotools-ами. Про то, чтобы использовать cmake на каком-нибудь мейнфрейме - можно вообще было не заикаться. А вот auoconf там работал отлично. > Да и вообще, autoconf скрипт, который умеет делать autoreconf не в папке с кодом -- это редкость. Блин, да банально сделать configure, способным собирать вне папки с кодом не у всех выходит. И думай потом, где нагенерено, а где реальный код. Аналогичная проблема есть и у cmake-а: если какой-то деятель запустил конфигурирование проекта в директории с кодом, то потом чистить её так же сложно как и automake-овский проект. Но всё же, я бы хотел ясно проартикулировать: то что какой-то автотулзовый проект не поддерживает out-of-source билд - это проблема конкретно этого проекта, а не автотулзов. Так же как бывают cmake-овские проекты, в которых out-of-source билды сломаны, несмотря на то, что написано в документации к самому cmake-у...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #35 Ответы: #61

57. Сообщение от slepnoga (ok), 10-Дек-20, 22:51	+/–
Где там? с готовым configure он не нужен, согласен ;) А если по полной - попробуй без miniperl, сообщиш результат
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #52

58. Сообщение от slepnoga (ok), 10-Дек-20, 22:53	+/–
Ну ка расскажи, при чем тут тулчейн и что ты под этим подразумеваешь
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #51 Ответы: #68

59. Сообщение от topin89 (ok), 10-Дек-20, 23:05	+/–
>> Я видел только одно преимущество -- генерация хелпа для ./configure. Вроде как такое можно сделать и для CMakeLists.txt, но на практике пока не встречал > В смысле? В option() в обязательном порядке прописывается строка справки. Выводится по > cmake -LH. Как я и говорил, редко встречал на практике. То что в принципе можно, это да
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #53

60. Сообщение от slepnoga (ok), 10-Дек-20, 23:07	+/–
>если проще с той же функциональностью нет той же функциональности с точки зрения мантайнера дистра, для пейсателя-смузихлеба да, цмаке одназначна проще, ибо УМВР достигается быстрее. Ну а как только овер 5 опций сборки - смузихлеб начинает в цмаке хардкодить или писать sh скрипты, ибо падать нормально на конфигуре при ненайденных опциях цмаке просто так не может - это же надо вручную говорить. Вобщем кто на что заточен - кто то то на УМВР с хер знает откуда подтенутыми либами ( где нашли, там и подтянули) и хрен переопределишь дирами, а кто то умеет на тулчейне с статик кросс sh+tinylibc  собрать glibc. Для примерчика - https://github.com/libguestfs/libguestfs/blob/master/configu... чето пока никто цмаке не осилил для этого проекта, хотя ужо скоро 10 лет, как мне  грозились сделать цмаке всякие смузики. Но как доходит до mixed sources -  тут вообще тушите свет, сливай воду ))))))))))))))))))))
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #42 Ответы: #70

61. Сообщение от topin89 (ok), 10-Дек-20, 23:10	+/–
> я бы хотел > ясно проартикулировать: то что какой-то автотулзовый проект не поддерживает out-of-source > билд - это проблема конкретно этого проекта, а не автотулзов. Так > же как бывают cmake-овские проекты, в которых out-of-source билды сломаны, несмотря > на то, что написано в документации к самому cmake-у... Всё так, но по ощущениям, большинство autotools-проектов строго in-source и большинство cmake-проектов как мининум поддерживают out-of-source. К минимум, для CMake нужно постараться, чтобы out-of-source _не_ поддерживался. Честно говоря, не знаю как именно в autoconf, но по ощущениям, нужно постараться как раз ради поддержки. Поправьте, если ошибаюсь.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #56 Ответы: #63

62. Сообщение от slepnoga (ok), 10-Дек-20, 23:20	+/–
>Что там делать вообще на этой платформе? Ну да,тыртрубовский плеер на кутях там точно не нужен, это ты прав. Прикинь, там то даже и видяшки нету, от слова совсем. И завозить никто не планирует. Зато, например, апстолы и бирд давно работают, угу, на 64 мб рамы. Ну или да,рамы уже 256 ГБ, но видяшка по прежнему нафик не нужна - для смузихлебов веб фейс, для инженегров - ssh консоль со смартом овер дохера ссдешек. Но вы продолжайте писать новые темы для кедов - там цмаке самое то
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #49 Ответы: #65, #67

63. Сообщение от Аноним (64), 11-Дек-20, 03:25	+1 +/–
> Честно говоря, не знаю как именно в autoconf, но по ощущениям, нужно постараться как раз ради поддержки. Поправьте, если ошибаюсь. Я бы сказал, что в в автотулзах как раз всё просто: srcdir, abs_srcdir, top_srcdir и abs_top_srcdir - это директории с исходниками, а builddir, abs_builddir, top_builddir и abs_top_builddir - это директории с билдом. Мнемоники, ИМХО, понятные (https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/a... ). Ты чётко знаешь что исходники у тебя в srcdir. Если у тебя есть какая-то генерация промежуточного кода, например, в lex-е, или yacc-е, то сгенерированный код должен оказаться в builddir. Там же должны оказаться объектники (цели сборки). Если тулза, которую ты используешь для генерации промежуточного кода тупая, то вместо srcdir и builddir нужно использовать полные пути (abs_srcdir и abs_builddir). Установка собранных целей - стандартна, вполне понятно описана (https://www.gnu.org/prep/standards/html_node/Directory-Varia... ) и не менялась годами. Её, обычно, изменять не нужно: бинарники попадают в $(DESTDIR)$(prefix)/$(bindir), библиотеки - в $(DESTDIR)$(prefix)/$(libdir) (https://www.gnu.org/prep/standards/html_node/DESTDIR.html ), но про это нужно вспоминать только если создаёшь специальные цели, типа install-data-local, или install-exec-hook в Makefile.am
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #61

64. Сообщение от Аноним (64), 11-Дек-20, 03:58	+/–
Триплет - это cpu-vendor-os (https://www.gnu.org/software/autoconf/manual/autoconf-2.70/h... ) Бывает полезен, если собираешь не нативный для этой системы код, например, на 64-х разрядной билдовой машине 32-ух разрядные бинарники. При кросс-компиляции, опять же.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #43

65. Сообщение от Ordu (ok), 11-Дек-20, 04:47	+/–
>>Что там делать вообще на этой платформе? > Ну да,тыртрубовский плеер на кутях там точно не нужен, это ты прав. > Прикинь, там то даже и видяшки нету, от слова совсем. И завозить > никто не планирует. > Зато, например, апстолы и бирд давно работают, угу, на 64 мб рамы. На 64мб рамы? Да там ты не то, что cmake, даже и компилятор запускать не захочешь и будешь собирать на другой машине. > Ну или да,рамы уже 256 ГБ, но видяшка по прежнему нафик не > нужна - для смузихлебов веб фейс, для инженегров - ssh консоль > со смартом овер дохера ссдешек. > Но вы продолжайте писать новые темы для кедов - там цмаке самое > то Что ты прицепился к видяшке? Среди депендансов выше нет ни одной, относящейся к выводу графики. Оно всё будет отлично работать без Xorg/Wayland, оно даже не заметит разницы.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #62

66. Сообщение от vle (ok), 11-Дек-20, 14:50	+/–
Кому это все надоело, можете попробовать https://github.com/cheusov/mk-configure Брать лучше последнюю версию.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #74, #75

67. Сообщение от Аноним (20), 11-Дек-20, 15:03	+/–
Этих 64 мб рамы не хватит, чтобы вместить весь нагенерённый автоконфом мусор. А cmake вполне заработает. Только зачем? Всё равно все здравомыслящие люди под такие платформы кроссом собираются, а не ждут по полчаса нативной сборки любого хелловорлда.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #62 Ответы: #78

68. Сообщение от Аноним (20), 11-Дек-20, 15:06	+/–
Это файлик такой. man cmake-toolchains. В нём всего лишь определяют несколько переменных, в том числе указывающих, где что надо искать.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #58 Ответы: #69

69. Сообщение от Аноним (20), 11-Дек-20, 15:07	+/–
Но вообще можешь с тем же успехом эти переменные и из командной строки передать. Это уж как больше нравится.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #68

70. Сообщение от Аноним (20), 11-Дек-20, 15:14	+/–
> нет той же функциональности с точки зрения мантайнера дистра А ты майнтейнер дистра? > как доходит до mixed sources Это что за разновидность неполовых извращений?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #60 Ответы: #71

71. Сообщение от slepnoga (ok), 11-Дек-20, 15:22	+/–
>А ты майнтейнер дистра А что, не похож? ))) Для ментейнера - когда программа написана на нескольких языках - в примере: C, ocaml, perl. Это не считая либ и биндингов
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #70 Ответы: #72

72. Сообщение от Аноним (20), 11-Дек-20, 17:29	+/–
> А что, не похож? Раз уходишь от ответа — значит, нет. Чего тогда берёшься рассуждать о чужом деле? (Да, я майнтейнер со стажем почти десяток лет. Да, мне намного приятнее иметь дело с cmake, чем с autocrap.)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #71 Ответы: #79

73. Сообщение от Аноним (73), 11-Дек-20, 19:37	+/–
>Чем вам CMake непортируемый? CMake 3.14.0 available for download Robert Maynard on March 14, 2019 Support for running CMake on Windows XP and Windows Vista has been dropped. https://blog.kitware.com/cmake-3-14-0-available-for-download/ Поясню, что мне попался опенсорс проект написанный для Borland 2006 (на плюсах) и автор никак не хотел его не портировать, не менять и т.д. Пришлось все делать самому. Столкнулся с проблемой, что нужно было собрать openssl для Borldand 2006 и статически его линкануть с приложением. Оказалось, что это в принципе несложно, т.к. некоторые люди до сих пор поддерживают проекты с _мэйкфайлами_ под этот Borland. Если не ошибаюсь, то именно так можно собрать zlib (т.к. в нем есть борландовский мейкфайл). И cmake мне тогда не помог. Это было до openssl 1.1.0. Возможно, что что-то стало проще или сложнее, но факт еще в том, что смешивать выхлопы от mingw (это типа новый путь из док) с borland cc, ну это такое себе извращение.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #23

74. Сообщение от Аноним (-), 11-Дек-20, 19:56	+/–
Интереса ради - почему не kconfig тогда уже сразу вместо двух нажатий клавиш для добавления опций сборки в автоконф ?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #66

75. Сообщение от Аноним (75), 11-Дек-20, 21:27	+1 +/–
> Брать лучше последнюю версию. Интересно, как этим пользоваться во фряхе, если первой строчкой в README говорится о том что фряшная версия bmake, сопровождением которой занимается sjg не годится? Еще один bmake ставить?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #66 Ответы: #81, #82

76. Сообщение от qwerty123 (??), 12-Дек-20, 00:47	+/–
>Так ничего, кроме GNU/Linux не осталось. Как минимум, *BSD & производные OpenSolaris. И не нуно про количество, "миллионы мух не дадут соврать"
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #19

77. Сообщение от qwerty123 (??), 12-Дек-20, 00:51	+/–
>> И как это влияет на портируемость? >они реально такие т*пые :-( >> Что-то я не вижу в зависимостях ничего непортируемого. >>Приступай к портированию. Вот как ВЕСЬ этот мусор спортируешь на какую-нибудь необычную платформу Оно не понимает, что эту хню и на обычной ARM банана-плате хрен скомпилируешь.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #46 Ответы: #80

78. Сообщение от qwerty123 (??), 12-Дек-20, 00:56	+/–
>Этих 64 мб рамы не хватит, чтобы вместить весь нагенерённый автоконфом мусор. Чувак, для работы configure минимально нужен sh и sed. Все. Такое впечатление, что ты Unix только на картинке видел.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #67

79. Сообщение от slepnoga (ok), 12-Дек-20, 11:56	+/–
Приятнее, так как: 1. Архитектуры у тебя скорее всего полторы. ( amd64/i386 && arm  и все это под glibc only ;)) ) 2. Опции сборки жестко зафиксированы ,т.е. обирается ли оно с другими --enable/disable - тебе накласть. Все равно кроме тебя и билд-фермы никто из сорцов не собирает. 3. Кросскомпиляция - это ведь магия :))) Все так?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #72 Ответы: #84

80. Сообщение от пох. (?), 12-Дек-20, 17:01	+/–
> Оно не понимает, что эту хню и на обычной ARM банана-плате хрен скомпилируешь. с урезанием части зависимостей - скомпилируешь, есть их у меня. Только такой cmake потом cможет собрать только, хехе, "часть" софта. Ну, правда, скорее всего остальная часть все равно бы не заработала. Но теперь вместо того чтобы чинить это (например, мной обожаемую зависимость от isal ) - ты сперва почини-ка сборку без cmake или вот своим "неполноценным" cmake - быстренько разобравшись, что там не так и зачем оно было. Мне-то проще сделать форк с голыми Makefile, все равно я ни байта обратно не собираюсь возвращать макакам. Но время на это будет безвозвратно потеряно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #77

81. Сообщение от пох. (?), 12-Дек-20, 17:19	+/–
> Интересно, как этим пользоваться во фряхе, если первой строчкой в README говорится да никак, "мы поддерживаем только новыйстандарт, а не эти ваши юникс-совместимые ненужно-системы!"
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #75 Ответы: #83

82. Сообщение от vle (ok), 12-Дек-20, 21:13	+/–
>> Брать лучше последнюю версию. > Интересно, как этим пользоваться во фряхе, если первой строчкой в README говорится > о том что фряшная версия bmake, сопровождением которой занимается sjg не > годится? Еще один bmake ставить? На сколько мне известно SJG занимается портированием bmake на все, что движется. При чем тут FreeBSD? Но вообще, с некоторых пор mk-configure работает с родным FreeBSD-шным make-ом, посколько его заменили NetBSD-шным. Несколько лет назад.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #75

83. Сообщение от vle (ok), 12-Дек-20, 21:15	+1 +/–
>> Интересно, как этим пользоваться во фряхе, если первой строчкой в README говорится > да никак, "мы поддерживаем только новыйстандарт, а не эти ваши юникс-совместимые ненужно-системы!" Ирония, конечно, понятна, но список поддеживаемых платформ у mk-configure сильно шире, чем "новыйстандарт". На всем этом mk-c регулярно тестируется.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #81

84. Сообщение от Аноним (20), 14-Дек-20, 01:37	+/–
1. Помимо перечисленных были, например, ppc64 (обеих ориентаций), mipsel, aarch64… 2. Ну в общем случае — да, сборка одна на все случаи жизни. А ты хочешь, чтобы тебе все n! возможных комбинаций собирали? Но проблем с отключением/включением опций в этой единственной сборке ни разу не было. Да и откуда б им взяться? Там же всё предельно просто. 3. Не знаю, где ты там магию нашёл. С autocrap изредка бывают косяки, если разработчик сильно налажал, а с cmake не припоминаю (хотя и там накосячить можно при желании, как и везде). (К сведению: все известные мне дистрибутивы общего назначения собираются нативно.)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #79

85. Сообщение от Аноним (85), 18-Дек-20, 12:01	+/–
Не то чтобы я cmake защищал, мне он самому не очень нравится по многим причинам, но... 1) даже рекурсивный трэш из ldd на моей системе 28 строчек вместо ваших 60, но его для оценки использовать вообще неправильно, потому что: 2) давайте всё-таки смотреть прямые зависимости. B readelf -d cmake их в 3-4 раза меньше (читать NEEDED)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #36

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема