Autotools: A Practitioner's Guide to GNU Autoconf, Automake, and Libtool

Это очень устаревшее издание. Актуальное тут: https://mesonbuild.com/Manual.html

Дистрибутив Gentoo использует make (это прописано в его PMS). Вот когда найдёте дистрибутив перешедший на ваш meson, тогда и приходите.

Автотулсы в 2023 году? Ты серьёзно?

Ты должен был написать 2к23.

Я согласен с тем, что современные тенденции к консолидации капиталов и поглощению бизнесов, централизации вычислительных мощностей в виде датацентров способствуют к переходу на web-технологии вообще, node.js в частности, и соответственно на npm.

Однако концептуально будущее за коммунизмом и p2p-технологиями, следует давать равные возможности всем людям, а значит должна быть возможность собирать всё независимо от олигархов типа Грефа.

Autotools ближе к циклу видео про примитивные технологии, в то время как npm требует закрытых технологий вроде реалтаймовых многопоточных сборщиков мусора, которые непросто воспроизвести из нулей и единиц.

Autotools

Стоит ли прочитать, читали ли вы эту книгу,

Нет.

какие книги по Autotools вы бы порекомендовали (желательно на русском языке).

Поищи что-нить типа «как избавиться от autotools и научиться писать мейкфайлы».

научиться писать мейкфайлы

ой, всё

make - это не autotools.

autotools это блоатварная ненужная надстройка над make. Идеи в их основе хорошие - автоматически сгладить все различия между разными ОС, но реализация не удалась.

По ссылке вредный совет.

Тут такое дело, команда Gentoo говорит, что она не очень любит Makefile, не хочет править баги (в документации и PMS), связанные с непроработанностью установки проектов с Makefile в PREFIX и с другими особенностями Gentoo. Они рекомендуют использовать Autotools. Вот прямо так. Не форкать же из-за этого дистрибутив?

Я хотел, но подумал, что всё скатится в срач про 200023 вместо обсуждения убогости автотулсов.

Автотулсы в 2023 году?

ox55ff - нет, ну а что хотел сказать комментатор?

Ты серьёзно?

Да, я серьёзно.

$sh ./autoconf.sh
$./configure ${CONFIGURE_OPTS}
$make
$sudo make install

просто 70-80% апстрима, который autotools завязан - идёт предконфигурированный уже.

Ближе к теме! Такой вопрос задан ещё в 2000-м году - Книги про automake,autoconf,libtool
что с книгами?

Это ты к чему?

Типа подтверждаешь что автотулс это надстройка над make?

Ещё и sudo :(

Ещё и sudo :(

Без него никак - не будет прав на запись в системные директории
Точнее без него можно, но тогда надо под админом сидеть, говорят сидеть под админом тоже плохо.

вместо обсуждения убогости автотулсов

В 2к23 году же!

вместо обсуждения убогости автотулсов

Основные недостатки технологии Autotools включают:

1. Отсутствие поддержки для новых языков программирования и платформ: Autotools может не поддерживать новейшие языки программирования и платформы, что может ограничивать его применение в некоторых проектах

2. Зависимость от сторонних инструментов: Autotools зависит от других инструментов, таких как make, gettext, pkg-config, GCC и binutils, что может усложнить процесс установки и настройки среды разработки

3. Необходимость поддержки разных версий инструментов: Autotools часто используется для сборки проектов на разных платформах и требует поддержки различных версий инструментов, что может усложнить процесс разработки и сопровождения проекта

4. Необходимость поддержки нескольких версий одновременно: Autotools может потребовать поддержки нескольких версий инструментов и зависимостей, что может увеличить сложность добавления новых функций и исправления ошибок

5. Низкая производительность: Autotools может быть медленным в сравнении с другими системами сборки, особенно на больших проектах с множеством зависимостей. Это может привести к увеличению времени сборки проекта

6. Сложность настройки и использования: Autotools требует создания и поддержки множества конфигурационных файлов, что может быть сложным для начинающих разработчиков и добавлять дополнительную сложность в процесс сборки проекта.

7. Плохая слинкованность документации: Хотя Autotools является популярной системой сборки, документация и поддержка сообщества слишком длинные. В результате, разработчики не могут быстро найти то, что нужно именно им.

Нет, нет, хз, хз, никакие.

Без него никак

Можно ставить локально, например, в $HOME/.local

А где ты живёшь? Я так, ради интереса спрашиваю.

Ты забыл про то, что ./configure – тормозное говно. Для многих пакетов сейчас ./configure занимает гораздо больше времени, чем собственно сборка самого кода. Потому что большая часть тестов в этом configure нахрен не нужна в 2023 году. Проверка наличия компилятора фортрана, проверка наличия stdio.h, проверка что char занимает ровно 8 бит, проверка ещё какого-нибудь бесполезного говна, которая могла быть актуальна в 1983.

За использования autoconf сейчас нужно арматурой в зубы бить, дабы неповадно было.

На странице 17 написано:
«you can’t ask Autoconf to compile, link, or run Java-based checks, because Autoconf simply doesn’t natively support Java.»

По-моему, это говорит о том, что Autotools плохо спроектирована (нехватает ему какой-то контейнеризации).

Зависимость от сторонних инструментов: Autotools зависит от других инструментов, таких как make, gettext, pkg-config, GCC и binutils, что может усложнить процесс установки и настройки среды разработки

Забыли такие копролиты и изотерические ЯП как Perl и M4.

Можно подумать, что если бы там вместо Perl было что-нибудь другое (типа Ruby) то было бы лучше… Вот сложно было написать всё на Си? Раз уж не смогли на bash.

$sh ./autoconf.sh

В книжке рекомендуют этот скрипт называть ./bootstrap.sh
(на странице 20)

Потому что большая часть тестов в этом configure нахрен не нужна в 2023 году. Проверка наличия компилятора фортрана,

А потом на чутка нестандартной системе весь этот cmake разваливается и глючит.

2. Зависимость от сторонних инструментов: Autotools зависит от других инструментов, таких как make, gettext, pkg-config, GCC и binutils,

Так и остальные тоже не из эфира знания о доступных возможностях софтовых компонентов берут, и компилируют не сами…

А поддержка многих версий всего лучше, чем прибитость гвоздями к «последней» версии, хотя бы даже для git bisect.

Найди мне систему, где заработает скрипт configure и при этом размер char не равен 1. Я подожду.

А cmake сосёт, да. Не понимаю, зачем фанаты автолулзов его постоянно вспоминают.

Не знаю как вам, а мне эту книжку читать трудно. Она же вся из воды. В третьей главе по-тихоньку начали что-то собирать, но…

Лучше бы существовала другая книжка, лучше бы это был викиучебник, в первой же главе надо было показать как собираются исполняемые файлы, во второй как собираются библиотеки, в третьей как линкуется одно к другому динамически, в четвёртой - как статически, остальные главы и приложения-аппендиксы посвятить описанию деталей и объяснениям того, как работают примеры из первой-четвёртой глав.

Например вот эта страница лучше по задумке - https://help.ubuntu.ru/wiki/using_gnu_autotools , но всё ещё недостаточно хороша по реализации. Не надо было разделять ссылки и текст.

И нет ещё трёх частей. Подобная «поверхностность» присуща большинству статей, например https://eax.me/autotools/

А потом на чутка нестандартной системе весь этот cmake разваливается и глючит.

Как раз на чутка нестандартной системе Craptools глючат и замучаешься искать как починить, а CMake и Meson работают нормально. Например Craptools может не знать что libdl может отсутствовать а её функционал это часть libc, libc называется по другому, а сетевые функции с сокетами находятся например в libnetwork.

Туда же

Кроме autotools совместимые с make файлы создаёт ещё несколько программ

Ну и что? Они не так хорошо известны, значит не так хорошо задокументированы.

Хорошая книга. Стоит читать, если ты хочешь понять как работают системы конфигурации и сборки, даже если применять на практике не придется.

это ты про Хайку? Ну так поддержка систем не растет сама из воздуха… Кто-то должен её сделать.

В CMake/Meson это обычно достаточно сделать один раз в самой системе сборки, а в Craptools надо отдельно патчить каждую программу и замучаешься искать как это делать потому что разные программы используют Craptools сильно по разному.

Дочитал третью главу. Написать ./configure руками они не смогли (нет примеров), значит без autotools никак.

Мне не очень понятно, зачем надо было писать часть кода пакета Autotools на языке программирования Perl. Наверное ведь можно было постараться написать на bash и не тащить лишнюю зависимость в систему.

Самый модный язык сейчас rust и я спросил у поисковика, что является там аналогом автотулсов, он мне ответил, что cargo. Но ведь cargo это система сборки, то есть, аналог make и Makefile, и немного пакетный менеджер. Какая связь между cargo и Autotools я не понял.

Чем ещё можно сгенерировать файл ./configure я не знаю. Советовали, конечно, CMake, но они это делали без уважения.

Если вам нужно сгенерировать файл ./configure с использованием альтернативных инструментов, вы можете рассмотреть следующие варианты:

CMake: CMake предоставляет команду configure_file, которая может генерировать файлы на основе шаблонов. Это может быть использовано для создания файла configure. Однако, это потребует написания дополнительного кода в вашем CMakeLists.txt для обработки аргументов командной строки и создания файла configure

Meson: Meson также предоставляет возможности для генерации файлов на основе шаблонов. Однако, Meson не генерирует файл ./configure в том смысле, в каком это делает Autotools. Вместо этого, Meson использует собственный формат файла для описания сборки проекта

SCons: SCons - это инструмент сборки, который использует Python в качестве своего скриптового языка. Вы можете написать скрипт на Python, который сгенерирует файл configure на основе ваших требований. Однако, это потребует знания Python и может быть более сложным, чем использование Autotools или CMake.

Пожалуйста, обратите внимание, что ни один из этих инструментов не генерирует файл ./configure в том же смысле, что и Autotools.

Ты там держись. Всего тебе доброго, хорошего настроения и здоровья!

Чем ещё можно сгенерировать файл ./configure я не знаю.

autogen.sh эта дерьмолапша создаётся

в котором последовательные вызовы autoconf или automake

всё скатится в срач

таков путь

Мне кажется неправильным, что .ebuild-файл для GNU Autotools размещается в категории sys-devel. Сделали бы себе категорию dev-c, и в ней бы разместили. В мире много современных пакетных менеджеров, но их выжимают в другие репозитории, такие как dev-rust, dev-java, dev-haskell и т.д. Вот и значимость autotools надо тоже понижать, уже пора сравнять по значимости языки си и rust.

Хотя вообще, если исходить из того, что она генерирует скрипты, то shell-scripts/autotools ? А если Autotools содержат код на perl, то тогда dev-perl ! или perl-m4-shell ?

Мусьё, верните машину времени обратно.