После восьми лет с момента публикации версии 2.69 представлен выпуск пакета GNU Autoconf 2.70, в котором поставляется набор M4-макросов для создания скриптов автоконфигурации для сборки приложений в различных Unix-подобных системах (на основе подготовленного шаблона выполняется генерация скрипта "configure")...Подробнее: https://www.opennet.dev/opennews/art.shtml?num=54226
старый, добрый, ламповый автоконф. Но и на солнце есть пятна, например можно было в config.log указывать строчку, где именно описывается вызов непрошедшего теста. Сэкономило б чутка времени при анализе окружения.
Кто хотел сэкономить время, те уже давно пользуются вменяемыми билд-системами, с которыми не надо продираться через три слоя автогенерированных скриптов под шеллы семидесятого года.
> Кто хотел сэкономить время, те уже давно пользуются вменяемыми билд-системамиа что "вменяемые" работают только под "новым стандартом" - так это неважно, код этих экономных тоже только в нем и работает, причем только с еще недонаписанными распоследними версиями ВСЕГО.
В целом, согласен, зачем бы им автоконф?
> с которыми не надо продираться через три слоя автогенерированных скриптов под шеллы
> семидесятого года.через них не надо "продираться", они просто делают свою работу. При условии что ты умеешь делать свою.
autoconf это немного не про твое неумение писать мэйкфайлы, это про портируемый софт, который вы теперь писать разучились.
> портируемый софтТак ничего, кроме GNU/Linux не осталось.
С такими желаниями вокруг тебя скоро никого, кроме альтернативно ориентированных, не останется.
дык, я и говорю - нах он не нужен тот автоконф.Ты еще забыл уточнить,конечно, что кроме (по тексту) самых наираспоследних версий, а кто не спрятался - сам виноват. А то можно посмотреть, к примеру, _правильное_ применение gnu autoconf в не то что linux-only, а при сборке драйвера ядра - ага, ZoL.
Но это совершенно неправильный, конечно, драйвер - "с 2.6.32 по 5.+", кто ж так пишет, кроме полных лохов-неудачников?!
А 99% реальных применений автоконфа - --with-ненужно или --enable-ненужно. Где автоконф тоже ненужно, совершенно.
> Так ничего, кроме GNU/Linux не осталось.так кроме GNU/Linux ничего не нужно.
а под портируемостью подразумевается поддержка разных аппаратных архитектур, а ненужных ОСей
> а под портируемостью подразумевается поддержка разных аппаратных архитектур,Угу, угу - обоих двух - amd64 и aarch64. Мозги при этом включать вообще не понадобится. Вон, берите пример с "мультиплатформенной" системы лохот...электрон!
(а то ж можно додуматься, что на какой-нибудь платформе твоих любимых готовых библиотечек - опаньки, а вообще ж нет. И не предвидится. Да ты ж модный пацан, не то что некоторые лохи, умеющие и в такое - нет, так заменим менее эффективным своим кодом, зато кроссплатформенным - ты просто скажешь "фуфуфу, фуфло ваша платформа, купите мак, как у всех!")
Хорошо бы в код еще пометочку какую сразу ставить, чтоб отличать подобные поделки от нормального софта с первого взгляда. А, ну да, ну да - уже ж поставлено. Использует не autotools и не самодельную им замену, написанную из разумных соображений - в помойку.
>[оверквотинг удален]
> (а то ж можно додуматься, что на какой-нибудь платформе твоих любимых готовых
> библиотечек - опаньки, а вообще ж нет. И не предвидится. Да
> ты ж модный пацан, не то что некоторые лохи, умеющие и
> в такое - нет, так заменим менее эффективным своим кодом, зато
> кроссплатформенным - ты просто скажешь "фуфуфу, фуфло ваша платформа, купите мак,
> как у всех!")
> Хорошо бы в код еще пометочку какую сразу ставить, чтоб отличать подобные
> поделки от нормального софта с первого взгляда. А, ну да, ну
> да - уже ж поставлено. Использует не autotools и не самодельную
> им замену, написанную из разумных соображений - в помойку.чё за х*ню я только что прочитал? О_О
какой-то текстовый артхаус
>Так ничего, кроме GNU/Linux не осталось.Как минимум, *BSD & производные OpenSolaris.
И не нуно про количество, "миллионы мух не дадут соврать"
> через них не надо "продираться", они просто делают свою работу. При условии что ты умеешь делать свою.Хреново делают только. Особенно если у тебя пачка библиотек, и приходится иметь дело с libtool. Там вообще тушите свет, сливайте воду.
Чем вам CMake непортируемый?
Тем, что он, внизапна, требует компиляции.
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ахринеть, да )))
И это не говоря про отсутствие жесткого триплета при конфигурировании - никогда не знаешь, есть ли автозависимости, и если есть, откуда оно их цепануло
> Тем, что он, внизапна, требует компиляции.И как это влияет на портируемость?
> ахринеть, да )))
Что-то я не вижу в зависимостях ничего непортируемого.
> И как это влияет на портируемость?они реально такие т*пые :-(
> Что-то я не вижу в зависимостях ничего непортируемого.
Приступай к портированию. Вот как ВЕСЬ этот мусор спортируешь на какую-нибудь необычную платформу - сможешь начать портировать собственно свой хеловрот из трех строк, который без него не собирается, потому что ты не умеешь в мэйкфайлы.
> Вот как ВЕСЬ этот мусор спортируешь на какую-нибудь необычную платформуЧто это за платформа, куда весь этот "мусор" ещё не спортировали? Кому она сдалась такая? Что там делать вообще на этой платформе? Ядро-то туда "спортировали"?
Платформа без софта -- это не платформа, а кусок железа. Чтобы сделать из неё платформу надо поработать руками.
> сможешь начать портировать собственно свой хеловрот из трех строк, который без него не собирается, потому что ты не умеешь в мэйкфайлы.
пох, ну сколько можно кривляться? Все вокруг тебя не осилили bash, make, бла-бла-бла... Что там осиливать? Не, ну ты сам-то осилил? И чо-как, неужели так сложно было, что теперь ты считаешь, что тебе есть чем гордиться?
>Что там делать вообще на этой платформе?Ну да,тыртрубовский плеер на кутях там точно не нужен, это ты прав.
Прикинь, там то даже и видяшки нету, от слова совсем. И завозить никто не планирует.
Зато, например, апстолы и бирд давно работают, угу, на 64 мб рамы.
Ну или да,рамы уже 256 ГБ, но видяшка по прежнему нафик не нужна - для смузихлебов веб фейс, для инженегров - ssh консоль со смартом овер дохера ссдешек.
Но вы продолжайте писать новые темы для кедов - там цмаке самое то
>>Что там делать вообще на этой платформе?
> Ну да,тыртрубовский плеер на кутях там точно не нужен, это ты прав.
> Прикинь, там то даже и видяшки нету, от слова совсем. И завозить
> никто не планирует.
> Зато, например, апстолы и бирд давно работают, угу, на 64 мб рамы.На 64мб рамы? Да там ты не то, что cmake, даже и компилятор запускать не захочешь и будешь собирать на другой машине.
> Ну или да,рамы уже 256 ГБ, но видяшка по прежнему нафик не
> нужна - для смузихлебов веб фейс, для инженегров - ssh консоль
> со смартом овер дохера ссдешек.
> Но вы продолжайте писать новые темы для кедов - там цмаке самое
> тоЧто ты прицепился к видяшке? Среди депендансов выше нет ни одной, относящейся к выводу графики. Оно всё будет отлично работать без Xorg/Wayland, оно даже не заметит разницы.
Этих 64 мб рамы не хватит, чтобы вместить весь нагенерённый автоконфом мусор. А cmake вполне заработает. Только зачем? Всё равно все здравомыслящие люди под такие платформы кроссом собираются, а не ждут по полчаса нативной сборки любого хелловорлда.
>Этих 64 мб рамы не хватит, чтобы вместить весь нагенерённый автоконфом мусор.Чувак, для работы configure минимально нужен sh и sed. Все.
Такое впечатление, что ты Unix только на картинке видел.
>> И как это влияет на портируемость?
>они реально такие т*пые :-(
>> Что-то я не вижу в зависимостях ничего непортируемого.
>>Приступай к портированию. Вот как ВЕСЬ этот мусор спортируешь на какую-нибудь необычную платформуОно не понимает, что эту хню и на обычной ARM банана-плате хрен скомпилируешь.
> Оно не понимает, что эту хню и на обычной ARM банана-плате хрен скомпилируешь.с урезанием части зависимостей - скомпилируешь, есть их у меня.
Только такой cmake потом cможет собрать только, хехе, "часть" софта. Ну, правда, скорее всего остальная часть все равно бы не заработала. Но теперь вместо того чтобы чинить это (например, мной обожаемую зависимость от isal ) - ты сперва почини-ка сборку без cmake или вот своим "неполноценным" cmake - быстренько разобравшись, что там не так и зачем оно было. Мне-то проще сделать форк с голыми Makefile, все равно я ни байта обратно не собираюсь возвращать макакам.
Но время на это будет безвозвратно потеряно.
> И это не говоря про отсутствие жесткого триплета при конфигурировании - никогда
> не знаешь, есть ли автозависимости, и если есть, откуда оно их
> цепанулоМожно подетальнее. Я не знаю, что значит "жесткий триплет при конфигурировании" и на что это влияет.
Триплет - это cpu-vendor-os (https://www.gnu.org/software/autoconf/manual/autoconf-2.70/h... )
Бывает полезен, если собираешь не нативный для этой системы код, например, на 64-х разрядной билдовой машине 32-ух разрядные бинарники. При кросс-компиляции, опять же.
> И это не говоря про отсутствие жесткого триплета при конфигурировании - никогда не знаешь, есть ли автозависимости, и если есть, откуда оно их цепанулоТриплет ему подавай… Тулчейн определи как доке описано, и не будет ничего цеплять откуда не надо.
Ну ка расскажи, при чем тут тулчейн и что ты под этим подразумеваешь
Это файлик такой. man cmake-toolchains. В нём всего лишь определяют несколько переменных, в том числе указывающих, где что надо искать.
Но вообще можешь с тем же успехом эти переменные и из командной строки передать. Это уж как больше нравится.
Не то чтобы я cmake защищал, мне он самому не очень нравится по многим причинам, но...
1) даже рекурсивный трэш из ldd на моей системе 28 строчек вместо ваших 60, но его для оценки использовать вообще неправильно, потому что:
2) давайте всё-таки смотреть прямые зависимости. B readelf -d cmake их в 3-4 раза меньше (читать NEEDED)
head -1 /usr/bin/autoconf
#! /bin/sh
такие дела, да: из депенсов по __максимуму__
sh, perl, m4
самое главное что для _сборки_ проекта (в том числе и модифицированного по месту) они _вообще_ не нужны.Нужен только примерно баш-совместимый шелл.
> из депенсов по __максимуму__
> sh, perl, m4Perl-то ты где там нашёл?
Где там? с готовым configure он не нужен, согласен ;)
А если по полной - попробуй без miniperl, сообщиш результат
> Чем вам CMake непортируемый?Не портируемый он тем, что он никогда не умел и всё ещё не умеет определять какие флаги нужны сишному компилятору на HP-UX и на AIX для безопасного использования потоков. По сути, он ничего кроме gcc -pthread и не знает. Модуль FindThreads.cmake - никчёмная ерунда.
>Чем вам 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, ну это такое себе извращение.
Всё это замечательно, но на практике с autoconf было сушественно больше мороки, чем с CMake.> а что "вменяемые" работают только под "новым стандартом" - так это неважно, код этих экономных тоже только в нем и работает, причем только с еще недонаписанными распоследними версиями ВСЕГО.
Ну внезапно, если есть возможность пользоваться последними стандартами -- ими и пользуются. Да и то, большинство библиотек работает на предыдущем стандарте, или стандарте на два поколения назад, для той самой совместимости. Или поддерживает оба стандарта, но старый в ограниченном режиме
> через них не надо "продираться", они просто делают свою работу. При условии что ты умеешь делать свою.
Конфиги автоконфа write-only что-ли?
> autoconf это немного не про твое неумение писать мэйкфайлы, это про портируемый софт, который вы теперь писать разучились.
Да как сказать, на CMake портируемый на Винду софт попроще писать получается. Да и под Андроид тоже.
Да и вообще, autoconf так себе система конфигурации, лучшее в ней то, что она была одной из первых.
Если не поставил gettext какой-нибудь -- падает с ошибкой, по которой никак не понять, что происходит. Если это такой стандартный инструмент, что не требует проверки на наличие, какого хрена его нет в зависимостях? В CMake всё в комплекте, а что нет, как правило ищется через find_package и если не находится, хотя бы ясно, чего не хватает.
Да и вообще, autoconf скрипт, который умеет делать autoreconf не в папке с кодом -- это редкость. Блин, да банально сделать configure, способным собирать вне папки с кодом не у всех выходит. И думай потом, где нагенерено, а где реальный код.
Я видел только одно преимущество -- генерация хелпа для ./configure. Вроде как такое можно сделать и для CMakeLists.txt, но на практике пока не встречал
>стандартный инструмент, что не требует проверки на наличие,Хоспади, ну собирайте своих котиков, плееры и мордокниги чем хотите - все равно bootstrap нового arch'a не для смузихлебов
>>стандартный инструмент, что не требует проверки на наличие,
> Хоспади, ну собирайте своих котиков, плееры и мордокниги чем хотите - все
> равно bootstrap нового arch'a не для смузихлебовА по существу можно?
А главное, что за дихотомия такая? Если инструмент сложный -- то это тру, если проще с той же функциональностью, но новее -- то сразу для смузихлёбов. Так можно что угодно объявить ненужным, даже C (Есть же B или асм).
Да и не такой уж CMake и новый, 20 лет уже.
>если проще с той же функциональностьюнет той же функциональности с точки зрения мантайнера дистра, для пейсателя-смузихлеба да, цмаке одназначна проще, ибо УМВР достигается быстрее. Ну а как только овер 5 опций сборки - смузихлеб начинает в цмаке хардкодить или писать sh скрипты, ибо падать нормально на конфигуре при ненайденных опциях цмаке просто так не может - это же надо вручную говорить. Вобщем кто на что заточен - кто то то на УМВР с хер знает откуда подтенутыми либами ( где нашли, там и подтянули) и хрен переопределишь дирами, а кто то умеет на тулчейне с статик кросс sh+tinylibc собрать glibc.
Для примерчика - https://github.com/libguestfs/libguestfs/blob/master/configu...
чето пока никто цмаке не осилил для этого проекта, хотя ужо скоро 10 лет, как мне грозились сделать цмаке всякие смузики. Но как доходит до mixed sources - тут вообще тушите свет, сливай воду ))))))))))))))))))))
> нет той же функциональности с точки зрения мантайнера дистраА ты майнтейнер дистра?
> как доходит до mixed sources
Это что за разновидность неполовых извращений?
>А ты майнтейнер дистраА что, не похож? )))
Для ментейнера - когда программа написана на нескольких языках - в примере: C, ocaml, perl. Это не считая либ и биндингов
> А что, не похож?Раз уходишь от ответа — значит, нет. Чего тогда берёшься рассуждать о чужом деле?
(Да, я майнтейнер со стажем почти десяток лет. Да, мне намного приятнее иметь дело с cmake, чем с autocrap.)
Приятнее, так как:
1. Архитектуры у тебя скорее всего полторы. ( amd64/i386 && arm и все это под glibc only ;)) )
2. Опции сборки жестко зафиксированы ,т.е. обирается ли оно с другими --enable/disable - тебе накласть. Все равно кроме тебя и билд-фермы никто из сорцов не собирает.
3. Кросскомпиляция - это ведь магия :)))
Все так?
1. Помимо перечисленных были, например, ppc64 (обеих ориентаций), mipsel, aarch64…
2. Ну в общем случае — да, сборка одна на все случаи жизни. А ты хочешь, чтобы тебе все n! возможных комбинаций собирали? Но проблем с отключением/включением опций в этой единственной сборке ни разу не было. Да и откуда б им взяться? Там же всё предельно просто.
3. Не знаю, где ты там магию нашёл. С autocrap изредка бывают косяки, если разработчик сильно налажал, а с cmake не припоминаю (хотя и там накосячить можно при желании, как и везде). (К сведению: все известные мне дистрибутивы общего назначения собираются нативно.)
> Конфиги автоконфа write-only что-ли?в целом да - написал один раз и забыл. Как оно и должно было быть.
> Да как сказать, на CMake портируемый на Винду софт попроще писать получается.
Не, не попроще. Потому что его писать приходится. Что с cmake, что без cmake. Я, если что, пытался тут. Нихрена cmake за меня не написал, представь себе! И я изрядно не рад был выяснять, как в нем вручную обойти проблему нетипичных зависимостей (вместо того чтоб возиться с сишным кодом, ради которого все затевалось) - и, честно говоря, голый мэйкфайл я бы для такого проекта быстрее написал.
Ну а что ms всосала cmake со всеми нужными деталями прямо в visual c, так что модному-современному "разработчику" вообще надо ответить на вопрос "откуда git clone" и оно все волшебным образом ему соберется - ну так ей тоже хотелось как попроще, а не чтоб ты мог писать переносимый код. Винда и новыйстандарт, и хватит всем.
> Если это такой стандартный инструмент, что не требует проверки на наличие, какого хрена его
> нет в зависимостях?вопрос к майнтейнеру твоего дистрибутива. Зависимости ему полагалось бы написать.
> В CMake всё в комплекте
собранном тебе MS. А что не в комплекте - то не работает.
Вообще, чтоб ты в курсе был, у cmake есть свои стопиццот опций сборки. Правда, большую часть их трогать нельзя, потому что соберется, но собрать ничего не сможет.Забавно, что пара из них порождала циклические зависимости.
> Я видел только одно преимущество -- генерация хелпа для ./configure. Вроде как такое можно сделать и для CMakeLists.txt, но на практике пока не встречалВ смысле? В option() в обязательном порядке прописывается строка справки. Выводится по cmake -LH.
>> Я видел только одно преимущество -- генерация хелпа для ./configure. Вроде как такое можно сделать и для CMakeLists.txt, но на практике пока не встречал
> В смысле? В option() в обязательном порядке прописывается строка справки. Выводится по
> cmake -LH.Как я и говорил, редко встречал на практике. То что в принципе можно, это да
> Всё это замечательно, но на практике с autoconf было сушественно больше мороки, чем с CMake.В моей практике с cmake-ом было СУЩЕСТВЕННО больше мороки на UNIX-ах, чем с autotools-ами. Про то, чтобы использовать cmake на каком-нибудь мейнфрейме - можно вообще было не заикаться. А вот auoconf там работал отлично.
> Да и вообще, autoconf скрипт, который умеет делать autoreconf не в папке с кодом -- это редкость. Блин, да банально сделать configure, способным собирать вне папки с кодом не у всех выходит. И думай потом, где нагенерено, а где реальный код.
Аналогичная проблема есть и у cmake-а: если какой-то деятель запустил конфигурирование проекта в директории с кодом, то потом чистить её так же сложно как и automake-овский проект. Но всё же, я бы хотел ясно проартикулировать: то что какой-то автотулзовый проект не поддерживает out-of-source билд - это проблема конкретно этого проекта, а не автотулзов. Так же как бывают cmake-овские проекты, в которых out-of-source билды сломаны, несмотря на то, что написано в документации к самому cmake-у...
> я бы хотел
> ясно проартикулировать: то что какой-то автотулзовый проект не поддерживает out-of-source
> билд - это проблема конкретно этого проекта, а не автотулзов. Так
> же как бывают cmake-овские проекты, в которых out-of-source билды сломаны, несмотря
> на то, что написано в документации к самому cmake-у...Всё так, но по ощущениям, большинство autotools-проектов строго in-source и большинство cmake-проектов как мининум поддерживают out-of-source. К минимум, для CMake нужно постараться, чтобы out-of-source _не_ поддерживался. Честно говоря, не знаю как именно в autoconf, но по ощущениям, нужно постараться как раз ради поддержки. Поправьте, если ошибаюсь.
> Честно говоря, не знаю как именно в 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
> уже давно пользуются вменяемыми билд-системами, с которыми не надо продираться
> через три слоя автогенерированных скриптов под шеллы семидесятого года.Да, там три слоя фекалий другого типа хомячков, а когда что-то ломается то вообще логов нет. Не говоря о том что build-deps более другие. В сабже configure по минимуму вообще послать может на системе с posix shell и более нифига. И это уже начало.
А зачем тебе их логи? Когда что-то сломается в модном мезоне или еще какой ереси - ты вряд ли сможешь это починить.
> Да, там три слоя фекалий другого типа хомячков, а когда что-то ломается то вообще логов нет.Ну не обязательно же речь о meson, чего ты?
Надеюсь, теперь книга John Calcote выйдет поскорее!
Автокрап сила
>Обеспечена совместимость с выпущенными в 2011 году стандартами C и C++.Не прошло и 10 лет!!!
Всё суетитесь?
Помню, когда прекратилась поддержка CentOS 5, в Firefox сразу перешли на GTK3 и PulseAudio. Сейчас, когда прекратилась поддержка CentOS 6, Autoconf 2.70 вышел. Эх, а ведь 2.69 это целая эпоха.
Сейчас, когда прекратилась поддержка CentOS вообще. https://www.opennet.dev/opennews/art.shtml?num=54219
Ну, как раз вовремя же. Пусть теперь шляпа сама это и опакечивает, если ей надо.
> Обеспечена совместимость с выпущенными в 2011 году стандартами C и C++.Сверил календарь.
Закопайте вы уже это. Самый большой позор гну/линукса. Есть божественный meson от RedHat.
Толстовато.
что толстовато? Никто в 2020 не хочет копаться в этом макроболоте.
> Никто в 2020 не хочет копаться в этом макроболотеИменно по-этому сверху накинули невнятный cmake и уродский json ? Уж лучше божественный autotools чем все эти портянки
json это не система сборки, а формат данных. Выучи хотя бы это.
Где ты нашёл "уродский json"?
Толстовато предлагать заменить его питоноболотом.
meson не имеет никакого отношения к питону, кроме того, что эталонная реализация на нём написана. Если она лично вас не устраивает, напишите свою на любимом русте, или хоть на си, только фракталу потом не показывайте.
Так других то и нет. И синтаксис DSL пихоноуродский. Cmake и то приятнее этого шита. И он хотя-бы makefiles генерить мне умеет, а не требует поставить каких-то там нинзя или еще какую неведому фигню.
Ога, я тоже это заметил.
> Есть божественный meson от RedHat.1) Не от редхат а от каких-то левых уродов, к тому же откровенно коммерческих.
2) Эти уроды к тому же крайнее недружелюбны и генерить мэйкфайлы в принципе не намерены. Вот что у этих кондомов точно не отнять так это комплекс богов, пихающих свое счастье в глотку лопатой.
Лично я считаю, что должна быть сквозная интеграция от сборщика до дистрибутива. Единый софт должен собирать софт, клепать артефакты, паковать их в пакеты дистрибутива и накатывать куда скажут.Чтобы любые зависимостей на всей длине цепочек могли решаться системно. Чтобы цикл от пуша до тестирования (как софта самого по себе так и пакета в целом) до публикации был как можно корче и безболезненнее.
...и всё это при том, чтоб в школу не ходить, уроки не учить, а весь день смотреть мультики и прочие тиктоки...
Вот они настоящие ценности! Не то что ваши meson'ы, c{q}make и прочие нинзя
> Добавлена поддержка повторяемых сборок, результат которых будет одинаковым на разных системах.Reproduction на 100% решалось устоновкой переменной среды и добавлением нескольких опций к gcc.
Не удивлюсь если работавшую как швейцарские часики reproduction (одно из требований безопасности) сегодня сломали.
Вирусогенерялка: https://www.opennet.dev/openforum/vsluhforumID9/10331.html
Кому это все надоело, можете попробовать https://github.com/cheusov/mk-configureБрать лучше последнюю версию.
Интереса ради - почему не kconfig тогда уже сразу вместо двух нажатий клавиш для добавления опций сборки в автоконф ?
> Брать лучше последнюю версию.Интересно, как этим пользоваться во фряхе, если первой строчкой в README говорится о том что фряшная версия bmake, сопровождением которой занимается sjg не годится? Еще один bmake ставить?
> Интересно, как этим пользоваться во фряхе, если первой строчкой в README говоритсяда никак, "мы поддерживаем только новыйстандарт, а не эти ваши юникс-совместимые ненужно-системы!"
>> Интересно, как этим пользоваться во фряхе, если первой строчкой в README говорится
> да никак, "мы поддерживаем только новыйстандарт, а не эти ваши юникс-совместимые ненужно-системы!"Ирония, конечно, понятна, но список поддеживаемых платформ у mk-configure
сильно шире, чем "новыйстандарт". На всем этом mk-c регулярно тестируется.
>> Брать лучше последнюю версию.
> Интересно, как этим пользоваться во фряхе, если первой строчкой в README говорится
> о том что фряшная версия bmake, сопровождением которой занимается sjg не
> годится? Еще один bmake ставить?На сколько мне известно SJG занимается портированием bmake на все, что движется.
При чем тут FreeBSD? Но вообще, с некоторых пор mk-configure работает с родным
FreeBSD-шным make-ом, посколько его заменили NetBSD-шным. Несколько лет назад.