В ОС Linux авторы программ традиционно наплевательски относятся к пользователям. Зачастую файлы README и INSTALL содержат недостоверную информацию о том, как собирать загадочные проекты этих сумрачных гениев. Поэтому, опытный Linux-пользователь должен уметь "на глаз" определять, какая система сборки используется в том или ином программном пакете. Определяется это, обычно, по составу файлов, которые находятся в корне проекта.

Для сборки программ в GNU/Linux используется (в основном) программа make, которая запускает инструкции из файла Makefile. Но поскольку дистрибутивов GNU/Linux много, и они все разные, то для того чтобы собрать программу, пришлось бы для каждого дистрибутива отдельно прописывать пути, где какие лежат библиотеки и куда лезть за заголовочными файлами. Программисты не могут изучать каждый дистрибутив и для каждого отдельно создавать Makefile. Поэтому придумали конфигураторы, которые «изучают» систему, и в соответствии с полученными знаниями создают Makefile. Но на конфигураторе они не остановились и придумали конфигураторы конфигураторов… Хорошая новость в том, что на этом они остановились.

Для сборки нам нужны компиляторы: они прописаны в зависимостях пакета build-essential, так что достаточно установить его со всеми зависимостями. Ещё нужны пакеты autoconf, automake и cmake, все это рано или поздно пригодится.

Autotools: Automake + Autoconf

Итак, чтобы собрать что-то из исходников, нужно сначала собрать конфигуратор configure. Если файл с таким именем уже есть в исходниках, то можно сразу запускать его. Но бывает так, что этого файла нет. Тогда, если это проект на c/c++, а не какой-нибудь Ruby или Go, то правила сборки конфигуратора configure могут быть описаны в файле configure.in или configure.ac. Если таковых файлов нет, то скорее всего используется какая-либо другая система сборки, например cmake.

Если есть файл configure.in

Итак, для сборки конфигуратора configure, в случае если файл configure.in существует, необходимо выполнить команду:

./bootstrap

или

./autogen.sh

Если таких скриптов в архиве не оказалось, то можно выполнить последовательно следующие команды:

aclocal # Подготовка макросов m4

autoheader # Создание файла config.h.in

# Генерация Makefile.in из Makefile.am и создание недостающих скриптов (например, install-sh)

automake --gnu --add-missing --copy --foreign

autoconf -f -Wall # Генерация файла configure

Все эти команды используют файл configure.in. После выполнения этих команд создастся файл configure.

Если есть файл configure.ac

В этом случае необходимо выполнить такие команды:

aclocal # Подготовка макросов m4

autoconf # Генерация файла configure

automake # Генерация Makefile.in из Makefile.am

# Очистка проекта от артефактов сборки, работает только если в проекте уже был

# создан (сгенерирован) файл Makefile

make --distclean (или make distclean)

В результате все так же появится файл configure.

Еще вариант для configure.in

Иногда бывает так, что в комплекте идут уже готовые файлы configure и configure.in. И вроде как можно было бы просто запустить configure, но он оказывается неработоспособным и выдает ошибки типа:

configure: error: cannot find install-sh, install.sh, or shtool in "." "./.." "./../.."

В этом случае для перегенерации configure надо запустить команду:

autoreconf -i

В результате будет сгенерован новый файл configure, с которым можно будет работать. Но и тут не все так просто: если файл configure.in был написан для одной версии autoconf, а у пользователя другая версия autoconf (пусть даже и более свежая, с совместимостью снизу-вверх никто не заморачивается), то далеко не факт, что обработка configure.in завершится успешно. Правда, иногда помогает повторный запуск с опцией -v (для отладочного вывода) команды autoreconf -v.

Использование конфигуратора configure

Далее необходимо запустить полученный конфигуратор для проверки наличия всех зависимостей, а также установки дополнительных опций сборки (если возможно) и просмотра результата установки (опционально - может не быть):

./configure

Внимание!

Иногда разработчики поставляют исходники, в которых одновременно присутствуют и файл autogen.sh и файл configure. Чаще всего это означает, что разработчики забыли исключить файл configure из комплекта поставки. По-хорошему, они должны были поставить только autogen.sh, чтобы он сгенерировал configure с учетом системы пользователя. Поэтому не стоит торопиться и сразу запускать configure. Возможно, стоит переименовать этот файл, запустить autogen.sh, и запустить новый configure. Если он не сработает, попробовать запустить старый configure.

Попадаются и такие проекты, в которых переход на autogen.sh либо заброшен, либо находится в начальной стадии. И центральным, генерирующим Makefile скриптом, является configure. Конечно, разработчики нигде об этом писать не будут, исходя из принципа что кому нужно - тот сам разберется. В этом случае нет смысла запускать autogen.sh, нужно расчитывать именно на configure.

Как было сказано выше, сборка программ под Linux - это особая магия, иногда требующая умения читать мысли незнакомых людей.

Конфигуратор configure построит Makefile основываясь на полученных знаниях и файле makefile.am. Можно передать конфигуратору опции, предусмотренные в исходниках программы, которые позволяют включать/отключать те или иные возможности программы, обычно узнать о них можно командой

./configure --help

Также есть набор стандартных опций, вроде

--prefix=

которая указывает, какой каталог использовать для установки. Для Ubuntu обычно

--prefix=/usr

или

--prefix=/usr/local

Пути указываются без слеша в конце!

Ошибки в configure

В процессе работы configure возможно возникновение ошибок. Чаще всего ошибки будут возникать из-за того, что некоторые пакеты или dev-пакеты не установлены. Вот как выглядят ошибки:

configure: no Berkeley DB version 4.1 or higher found

configure: error: BerkeleyDB (libdb) not found.

...

checking for library containing poptGetContext... no

configure: error: POPT (libpopt) not found.

В этом случае надо доустанавливать из репозитария пакеты libdb5.3, libdb-dev, libpopt0, libpopt-dev. Как конкретно называются пакеты - зависит от дистрибутива. Чаще всего, опытные линуксоиды, "примерно", по логике вещей находят похожие названия пакетов (по части имени), и из них выбирают те что надо доустановить. После чего снова необходимо запустить configure, и так до тех пор, пока не исчезнут все ошибки.

Иногда может получиться так, что нужная библиотека и ее заголовочные файлы в системе установлены, но configure её упорно не видит. В этом случае надо пробовать использовать опции, которые (возможно) будут написаны в самой ошибке, чтобы через них указать путь к заголовкам библиотеки. Если же в тексте ошибки не сказано через какую опцию задается проблемный путь, надо пытаться читать выхлоп configure --help, в котором (возможно) будет написано через какие опции задаются пути. Либо надо копировать текст ошибки и искать решение в Интернете.

Признаком того, что configure правильно отработал, будет появление файла Makefile.

Cmake

Если в проекте имеется файл CMakeLists.txt, то скорее всего, проект надо собирать через утилиту cmake.

Традиционно, сборка проекта с cmake, если не оговорено отдельно, производится следующим образом:

1. Создать в каталоге корня проекта подкаталог build. Корень проекта определяется, обычно, по тому, что в нем лежит файл CMakeLists.txt.
2. Перейти в подкаталог build
3. Выполнить команду:

cmake ..

Для команды cmake может потребоваться указать еще какие-то дополнительные опции, типа:

cmake .. -DCMAKE_INSTALL_PREFIX=/usr

В любом случае, после этой команды, в каталоге build должны появиться разные файлы, и среди них обязательно должен быть Makefile. Вместо того, чтобы после команды cmake давать команды make и make install, можно, находясь в каталоге build, дать такую команду:

cmake --build . --target install --config Release

То есть, саму сборку и установку можно запустить не средствами make, а средствами cmake.

Для справки. Вот какие переменные чаще всего используются для конфигурирования команды cmake и указываются в ее опциях:

-DCMAKE_BUILD_TYPE=Release - Собрать релизную версию

-DCMAKE_BUILD_TYPE=Debug - Собрать отладочную версию

-DCMAKE_INSTALL_PREFIX - В какой каталог установить собранную программу или библиотеку. По сути, задается путь, куда будет копироваться бинарник или библиотека при выполнении команды make install.

-DCMAKE_PREFIX_PATH - В каком каталоге искать дополнительные библиотеки и файлы конфигурации с расширением *.cmake, необходимые для сборки проекта. По заданному пути будут искаться следующие типы файлов:

• Библиотеки (.so, .dll, .a).
• Заголовочные файлы (.h, .hpp).
• Настроечные файлы (например, Qt5Config.cmake для Qt).
• Файлы конфигурации cmake (<PackageName>Config.cmake, <package-name>-config.cmake).

По сути, данный путь будет дополнительно учитываться если в CMakeLists.txt будет использоваться функция find_package() или find_library(), в параметре которой указывается ИмяПакета. Однако, путь в переменной CMAKE_PREFIX_PATH используется не напрямую, а по следующим хитрым правилам:

• путь/lib/cmake/<ИмяПакета>/.
• путь/lib64/cmake/<ИмяПакета>/.
• путь/share/<ИмяПакета>/.
• путь/bin/ (для инструментов, например, protoc).

То есть, путь в CMAKE_PREFIX_PATH указывается до каталога, где лежит подготовленный для использования проект по стандарту cmake. В пути не указываются .../lib/cmake, .../lib64 и тому подобное. Система Cmake сама будет пытаться искать нужные файлы в этих подкаталогах.

Если надо указать несколько путей, то значение опции надо обязательно заключить в кавычки, и прописать в них несколько путей, использую символы-разделители. Для Linux - это ";", для Windows это ":". Использовать несколько опций -DCMAKE_PREFIX_PATH в одной команде нельзя.

Проекты с двумя системами сборки: autotools и cmake

Да, встречается и такая дичь. С корне проекта лежат файлы и от autotools и от cmake. Чаще всего это означает различные варианты состояния проекта:

1. Авторы начали переезд на новую систему сборки, но еще не довели его до конца. (Чаще всего переезд идет в направлении automake -> cmake).
2. Авторы переехали на новую систему сборки, но не удалили файлы старой, "на всякий случай". При этом поддержка старой системы сборки прекращена.
3. Авторы поддерживают обе системы сборки, чтобы проект мог собираться на бОльшем количестве дистрибутивов Linux.
4. Для сборки проекта, авторам действительно требуется обе системы сборки.

Понять, в каком состоянии находятся исходники, обычно очень сложно. Иногда авторы пишут информацию о том как собирать проект в файлах README и INSTALL. Но чаще всего не пишут. Предполагается, что человек, получивший исходники, прекрасно осведомлен о состоянии дел в проекте, несколько месяцев читал список рассылки, читает все новости о проекте, участвует в рабочих группах. Зачем держать документацию актуальной? И так все все знают! Наверно. А кто не знает - пусть идет лесом. Это опенсорч! Тут никто никому ничего не должен!

Нужен пример? Пожалуйста: библиотека libpoppler.

В общем, пользователю надо волшебным образом узнать в каком состоянии находятся исходники в данный момент. И принять соответствующее решение, как собирать проект.

Еще можно попробовать вначале собрать проект через autotools, а если не получилось - через cmake. Главное помнить, что собирать надо отдельно, сделав копии каталогов с исходниками: в одной копии запустить autotools, в другой - пробовать сборку через cmake.

Qmake

Если проект написан на Qt, то он, скорее всего, собирается через qmake (верно для Qt 3, 4, 5). Признаком того, что проект написан на Qt, является наличие файла с расширением *.pro, - это и есть файл Qt пректа. Утилита qmake делает на основе *.pro-файла файл Makefile.

Команда сборки, обычно, следующая. В каталоге, где лежит *.pro-файл необходимо выполнить:

qmake .

Да, надо обратить внимание, что команда пишется с точкой на конце. Точка означает текущий каталог. После работы данной команды, должен появиться файл Makefile, и можно будет запускать make. Следует учесть, что для успешной сборки qt-проекта, в системе должен быть установлен и фреймверк Qt соответствующей версии, и dev-пакеты к нему.

Make

make - это утилита, ради которой все вышеперечисленное и затевалось. Утилита make занимается, непосредственно, сборкой проекта. Для работы make необходимо наличие Makefile (мейкфайла), который создавался на предыдущих шагах. Запуск процесса сборки производится командой:

make

Для сборки достаточно привелегий обычного пользователя. Окончанием сборки можно считать момент, когда команда в консоли закончит свое выполнение и не будет слова error. Теперь всё скомпилировано и готово для установки.

Сама установка происходит под пользователем root с помощью команды:

make install

Либо, если необходимо установить программу через пакетный менеджер, создается пакет через программу checkinstall с соответсвующими для текущего дистрибутива опциями. Некоторые дистрибутивы представляют собственные средства установки и генерации пакетов. Описание подобного программного обеспечения в задачу данной статьи не входит. Пользователю придется ознакомиться с ними самостоятельно.