Autoconf ubuntu что это
Обновлено: 02.07.2024
Не редко необходимые пакеты можно найти только в виде исходных текстов, в данной статье описывается метод установки пакета из исходных текстов.
Программы обычно распространяются в упакованных архивах, это файлы с расширениями
Нужно понимать отличие между архиватором и упаковщиком.
Для архивации директорий и файлов используется программа tar; результатом её работы является файл с расширением .tar. Грубо говоря, это копия файловой системы - директорий и файлов с их атрибутами и правами доступа, помещённая в один файл.
Данный файл по размеру будет чуть больше, чем суммарный размер файлов, которые были архивированы. Поэтому (а может и по другой причине) используют упаковщики - программы, которые позволяют уменьшить размер файла без потери данных.
Программа tar умеет распаковывать, поэтому не нужно вызывать gunzip, а можно просто указать программе tar, что файл нужно cначала распаковать. Например, команда
сразу распакует и разархивирует. Отличие файлов с расширениями
лишь в том, что использовались разные упаковщики, программа tar определяет метод сжатия автоматически и дополнительных опций в данном случае не требуется.
После распаковки необходимо перейти в полученный каталог, все описываемые ниже команды выполняются в каталоге с исходными текстами пакета.
Для сборки программ в GNU/Linux используется (в основном) программа make, которая запускает инструкции из Makefile, но поскольку дистрибутивов GNU/Linux много, и они все разные, то для того чтобы собрать программу, нужно для каждого дистрибутива отдельно прописывать пути,где какие лежат библиотеки и заголовочные файлы. Программисты не могут изучать каждый дистрибутив и для каждого отдельно создавать Makefile. Поэтому придумали конфигураторы, которые «изучают» систему, и в соответствии с полученными знаниями создают Makefile. Но на конфигураторе они не остановились и придумали конфигураторы конфигураторов …на этом они остановились
Для сборки нам нужны компиляторы: они прописаны в зависимостях пакета build-essential, так что достаточно установить его со всеми зависимостями. Ещё нужны autoconf и automake.
Итак, чтобы собрать что-то из исходников, нужно сначала собрать конфигуратор; как собрать конфигуратор, описано в файле configure.in. Для сборки конфигуратора необходимо выполнить
Если таких скриптов в архиве не оказалось, то можно выполнить последовательно следующие команды:
Все эти команды используют файл configure.in. После выполнения этих команд создастся файл configure. После этого необходимо запустить конфигуратор для проверки наличия всех зависимостей, а также установки дополнительных опций сборки (если возможно) и просмотра результата установки (опционально- может не быть)
Конфигуратор построит Makefile основываясь на полученных знаниях и файле makefile.am. Можно передать конфигуратору опции, предусмотренные в исходниках программы, которые позволяют включать/отключать те или иные возможности программы, обычно узнать о них можно командой
Также есть набор стандартных опций, вроде
, которая указывает, какой каталог использовать для установки. Для Ubuntu обычно
БЕЗ слеша в конце! Теперь можно запустить процесс сборки самой программы командой
Для сборки достаточно привелегий обычного пользователя. Окончанием сборки можно считать момент, когда команды в консоли перестанут «беспорядочно» выполняться и не будет слова error. Теперь всё скомпилировано и готово для установки.
Усилия потраченные на Правильную установку в последствии с лихвой окупятся в случае удаления или обновления устанавливаемого программного обеспечения.
Правильная установка(Вариант №1)
Установка при помощи утилиты checkinstall. Для установки выполните
Минус данного способа: checkinstall понимает не все исходники, поскольку автор программы может написать особые скрипты по установке и checkinstall их не поймёт.Для создания и установки deb-пакета необходимо выполнить
Правильная установка(Вариант №2)
Быстрое создание deb-пакета «вручную».
Основное отличие от предыдущего способа заключается в том, что в данном случае вы создаете пакет вручную и отслеживаете все вносимые изменения. Так же этот способ подойдет вам, если исходники не поддерживают сборку пакета с checkinstall. Производим установку во временную директорию, где получаем весь набор устанавливаемых файлов: Создадим в «корне пакета» директорию DEBIAN и сложим в DEBIAN/conffiles список всех файлов, которые должны попасть в /etc: После чего создаём файл DEBIAN/control следующего содержания: При необходимости там же можно создать скрипты preinst, postinst, prerm и postrm. Получаем на выходе tempinstall.deb, который и устанавливаемУстановка (вариант №3)
Процедура создания deb-пакета подробно описана в данной статье.
Неправильная установка
Минус данного способа заключается в том, что если вы устанавливаете напрямую через make install, то нормально удалить или обновить пакет вы, скорее всего, не сможете. Более того, установка новой версии поверх старой, скорее всего, затрёт ваши изменения в конфигах. make install делает ровно то, что ему сказано — производит установку файлов в нужные места, игнорируя тот факт, что там что-то уже есть. После этого процесса совершенно никакой информации о том, что и куда ставилось, получить в удобоваримом виде невозможно. Иногда, конечно, Makefile поддерживает действие uninstall, но это встречается не так часто, да и не факт, что корректно работает. Кроме того, вам будет необходимо хранить для деинсталяции распакованное дерево исходников и правил сборки.Для установки необходимо выполнить
Для удаления пакета, установленного данным способом необходимо выполнить в корневой директории исходников программы (там где вы запускали make install).
Пакеты с буквами mm в конце описания — это пакеты для C++ программ. Список для bmpx, но подойдёт почти для любой GTK2/Gnome программы. Так что если не получается собрать, то посмотрите на этот список и сверьте с тем что у вас установлено.
Так же следует понимать, что именно autoconf системой сборки не является вообще, это система конфигурации перед сборкой. autoconf почему-то многие считают неким монстром, «проверяющим 15 давно несуществующих версий компилятора Fortran, а потом поддержку ключей этими компиляторами», что не совсем верно, ибо оно делает ровно то, что ему скажут. Другое дело, что многие просто копипастят его конфиг из проекта в проект, в итоге результат получается ужасающим.
В данной статье (планируется всё же осилить цикл) я хотел бы рассказать про autoconf, зачем он нужен и как его использовать.
N. B. К статье я подготовил архив с исходниками, можно его скачать.
Лучше всего пояснить, зачем используется autoconf на простом примере сферической программы в POSIX-окружении.
Итак, предположим, у вас есть программа, состоящая из одного исполняемого файла, которая читает строку из конфига и пишет в лог. Это неплохой сферический пример, так как очень многие программы помимо своей полезной нагрузки именно это и делают:
И простой Makefile для её сборки:
Если в процессе прочтения будут какие-то вопросы по Makefile-ам, настоятельно рекомендуется прочитать доку по make.
В принципе, бери да пользуйся, но по-хорошему программу надо бы в систему ещё и установить. Догадаться о том, что надо скопировать исполняемый файл в /bin можно, но лучше всё же сделать цели install и uninstall заодно:
install — *nix-овая утилита, которая помимо копирования файла выполняет манипуляции с правами доступа к нему.
DESTDIR здесь нужен, чтобы была возможность проводить установку не сразу в систему, а во временную директорию, чтобы система сборки пакетов могла их оттуда вычитать и упаковать. Мы же помним, что использовать make install напрямую — это очень плохо, правда?
Остаётся одна немаловажная проблема — все пути у нас захардкодены. Если кому-то нужно установить программу в домашнюю директорию, в /opt/ или просто используется дистрибутив, чихать хотевший на FHS, возникнут проблемы.
В принципе, мы можем принимать пути к нужным директориям в качестве аргументов make как делаем это с DESTDIR (make переопределяет заданные в Makefile значения, так что можно сделать и умолчания. Для начала модифицируем исходный код:
Теперь добавим определения нужных путей в Makefile, попутно вынеся их в CFLAGS, чтобы было удобнее реиспользовать при компиляции нескольких файлов, а так же модифицируем цели install и uninstall:
Уже намного лучше. Мы можем сделать make prefix=/opt/hellolog && make install prefix=/opt/hellolog и изолировать файлы своей программы в этой директории. Проблема теперь в том, что целей сборки может быть больше, и каждый раз писать кучу параметров не вполне удобно. По-хорошему всё надо вынести в некий настроечный скрипт, который получит параметры конфигурации, а в дальнейшем просто использовать make.
В бородатые времена такие скрипты писались вручную, заодно в целях переносимости кода (это у нас тут только POSIX используется, в настоящих программах ещё куча библиотек, причём некоторые из них взаимозаменяемы в какой-то части) в него включали проверки зависимостей и платформозависимые изменения логики Makefile. В какой-то момент количество скриптового кода, который передовой китайской техникой реиспользования кода под названием «копипаст» переносился из проекта в проект, стало превышать мыслимые пределы. В итоге один находчивый человек решил вынести часто используемые куски в макросы на M4 (M+4 буквы слова Macro, язык макросов разработанный Керниганом и Ритчи), что вылилось в autoconf. В дальнейшем он получил большое распространение, а затем на его инфраструктуре были созданы инструменты automake и libtool. Тем не менее, суть autoconf осталась прежней (набор макросов) и он может с успехом использоваться отдельно.
Посмотрим, что мы можем сделать с нашей игрушечной программой. В принципе, набор изменений крайне небольшой и касается только Makefile. Предопределёные значения путей заменим на placeholder-ы, а сам Makefile переименуем в Makefile.in:
Так же добавим минимально полезный конфигурационный файл configure.ac:
Запускаем autoreconf и получаем в текущей директории файл configure, который имеет всем привычный формат командной строки. Делаем ./configure --prefix=/opt && make && ./hellolog и видим, что все пути прописаны правильно. Теперь посмотрим, что же произошло «под капотом».
Единственный файл, который принимает autoconf — это configure.ac, являющийся обычный Bourne-shell скриптом, использующим макросы, соответственно AC_INIT и AC_OUTPUT являются обязательным скелетом, AC_CONFIG_FILES же указывает список файлов, в которых необходимо провести подстановки. Тут же можно сделать ещё кучу разных действий наподобие проверки наличия зависимостей. Я рекомендую для этого использовать pkg-config, для него существует отдельный набор макросов. Далее генерируется скрипт configure, которому не нужно ничего кроме Bourne-совместимого шелла и awk (раньше использовался sed).
./configure в свою очередь после проверок генерирует скрипт config.status, содержащий нужные параметры подстановки и запускает его. А тот уже в свою очередь генерирует файлы со значениями этих подстановок. Так что если у вас поменялся только Makefile, то достаточно запустить лишь config.status.
Итого, тулчейн выглядит так: autoreconf + configure.ac -> configure -> config.status -> итоговые файлы.
В принципе, ничто не мешает использовать autoconf вместе с вашей любимой средой сборки. Я, например, использую с MSBuild для своих программ, заточенных под Mono, Makefile-враппер для этого тривиален.
Примечания
1. die (читается как «ди») — определённый артикль множественного числа в немецком.
Говорим о принципах работы этого P2P-протокола и проектах, построенных на его основе.
/ Unsplash / Alina Grubnyak
Что такое Dat
Его участники разрабатывают сервисы, способствующие улучшению муниципальных услуг. Dat создавался как инструмент для передачи персональных данных граждан между гос. организациями. Но позже фокус проекта сместился в сторону научной информации.
Вокруг Dat сформировалось крупное сообщество (7 тыс. звезд на GitHub). Продвижением протокола и построенных на его основе приложений занимается некоммерческая организация Dat Foundation. Её поддерживают Mozilla, открытый фонд Code for Science & Society и разработчик P2P-сетей Wireline.
Как он работает
Для загрузки файла в сети Dat необходимо указать его URL. Вот пример:
О других протоколах и стандартах в нашем блоге на Хабре:
Когда пир узнает IP-адрес и номер порта другого пира, они устанавливают TCP-соединение. Все передаваемые данные шифруются — для этого используется система поточного шифрования XSalsa20. Алгоритм применяет хеш-функцию с двадцатью циклами. Операции преобразования напоминают те, что задействованы в AES.
Данные в Dat-сети передаются отдельными фрагментами (chunks), размеры которых могут отличаться. Система позволяет добавлять новые фрагменты в Dat-файл, но не разрешает модифицировать или удалять существующие. По словам разработчиков, такой подход позволяет сохранить всю историю изменения документов. Система получает возможность свободно функционировать в условиях с нестабильным подключением.
/ Unsplash / Sven Brandsma
Сейчас члены Dat Foundation улучшают протокол, чтобы он мог работать с большими объемами данных. В частности, планируют переработать файловую систему (называется Hyperdrive), чтобы она справлялась с миллионами файлов, и внедрить новые механизмы поиска пиров (Hyperswarm).
Кто использует
Примером может быть открытый проект ScienceFair. Это — десктопное приложение для просмотра и поиска научной литературы. На этой платформе ученые и исследователи могут работать с личными заметками, журналами или выжимками из них. Для отображения контента из научной литературы ScienceFair использует ридер Lens — он отвечает за рендер формата JATS XML.
Хотя Dat изначально задумывался как протокол для обмена научной информацией, комьюнити использует его для создания веб-сайтов, чатов и других приложений.
Один из свежих примеров — P2P-браузер Beaker, который разработан в партнерстве с командой, развивающей Dat. Его цель — дать пользователям возможность размещать веб-сайты «прямо в браузере». Авторы Beaker запустили облачный сервис Hashbase, поддерживающий постоянный доступ к Dat-сайтам, чьи локальные копии недоступны.
Проект полностью открыт, и его исходники можно найти на GitHub. Если вы хотите оценить возможности браузера самостоятельно, то для его запуска на Linux понадобится установить libtool, m4 и autoconf:
После достаточно запустить:
Больше примеров приложений можно найти на сайте проекта.
Аналог
Решение уже использует хостинг Neocities и маркетплейс OpenBazaar. Разработчики протоколов, подобных IPFS и Dat, надеются, что их проекты дадут интернет-пользователям больше контроля над своими данными.
О чем мы пишем в корпоративном блоге VAS Experts:
Прежде чем разбираться с вопросом автоматизации сборки своей копии программы “hello, world!” будьте уверены, что вы можете её написать. В любом случае, вот вам пример этой программы на языке Си:
Создание configure.in
Те, кто внимательно прочитал всю, или хотя бы бОльшую часть мануала (см. раздел Ссылки), без особых усилий смогут самостоятельно создать configure.in. Для таких же новичков как мы была создана программа autoscan, которая сканирует текущий каталог и создаёт заготовку для будущего configure.in файла. После запуска autoscan найдите в текущем каталоге файл configure.scan
Вот пример configure.scan, который получился у меня:
Переименуйте этот файл в configure.in и отредактируйте.
Первым макросом идёт AC_PREREQ. Он указывает, что требуется autoconf версии 2.59 и никак не меньше. В случае, если мы попытаемся создать configure скрипт с помощью autoconf более младшей версии мы получим ошибку.
Любой configure.in должен начинаться с макроса AC_INIT и заканчиваться макросом AC_OUTPUT. В качестве аргументов AC_INIT принимает название программы, её версию, и, как необязательный аргумент, ваш email-адрес, куда пользователи смогут отправлять отчеты об ошибках.
Не забудьте изменить значения по умолчанию для этих параметров! AC_CONFIG_SRCDIR принимает в качестве параметра путь к файлу, с которого начинается сборка. Т.к. в нашей программе файл пока всего один, то именно он и является аргументом этого макроса.
Более подробное описание для всех этих макросов вы можете найти в разделе ссылок внизу 1) .
После всех правок я получил следующий configure.in:
Теперь запустите программу autoconf, а после получившийся configure скрипт:
Создание Makefile.am и src/Makefile.am
Но работающего скрипта configure недостаточно. Наша цель, чтобы программа также собиралась по команде make и устанавливалась по make install. За это отвечает уже automake. Для него нам потребуется создать два файла: корневой Makefile.am и Makefile.am для каталога src/, в котором и должен располагаться файл hello.c
Для нашей программы они очень простые:
Объясню подробнее назначение добавленных макросов: AM_INIT_AUTOMAKE сообщает autoconf о том, что мы намерены использовать automake. AC_CONFIG_FILES говорит, что из указанных файлов, с постфиксом .in, нужно создать результирующие файлы с приведёнными именами. Иными словами, во время вызова configure из файла Makefile.in будет создаваться Makefile. (А Makefile.in создаётся автоматически из Makefile.am)
Читайте также: