8.2 Сборка приложений

Теперь, поняв процедуру сборки ядра, мы переходим к сборке программ пользовательского пространства. Эта область очень разнообразна; здесь может быть бесчисленное множество механизмов сборки, используемых отдельными пакетами. Однако, большая часть программ с открытым кодом для конфигурации и сборки следует общепринятому методу. Учитывая большое количество программ с открытым исходным кодом, которые могут быть развёрнуты на встраиваемых системах, понимание этой темы может облегчить перенос общедоступных программ с открытым кодом на вашу целевую плату. Также вы захотели бы настроить процедуру сборки, чтобы убедиться, что для сборки программы не выбраны нежелательные компоненты; это гарантирует, что ваше драгоценное дисковое пространство не будет потрачено на хранение ненужных программ.

Как и ядро, приложения также должны быть собраны с использованием инструментов кросс-разработки. Большинство программ с открытым кодом следуют стандарту сборки GNU. Система сборки GNU решает следующие вопросы переносимости:

▪Аппаратные различия, такие как порядок байтов, размеры типов данных и так далее

▪Различия ОС, такие как соглашения об именовании файлов устройств и так далее

▪Различия в библиотеках, такие как номер версии, аргументы API, и так далее

▪Различия в компиляторах, такие как имя компилятора, аргументы и так далее

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

▪autoconf: служит общей основой переносимости, основываясь на тестировании функций базовой системы на этапе сборки. Это делается проведением тестов для обнаружения особенностей базовой машины.

▪automake: это система для описания того, как собрать программу, что позволяет разработчику писать упрощённый Makefile.

▪libtool: это стандартизированный подход к построению общих библиотек.

Следует отметить, что понимание этих инструментов является главной задачей только если разработчик приложения намерен создать приложение, которое будет использоваться на различных платформах, включая различные аппаратные архитектуры, а также различные платформы UNIX, такие как Linux, FreeBSD и Solaris. С другой стороны, если читатель заинтересован только в кросс-компиляции приложения, то всё, что нужно сделать, это ввести в командной строке следующую команду:

# ./configure

# make

В этой главе мы вкратце обсудим различные части, которые помогают скрипту конфигурации сгенерировать файлы Makefile, необходимые для компиляции программы. Также мы предоставляем рекомендации по устранению неполадок и работе с некоторыми общими проблемами, которые возникают при использовании configure для кросс-компиляции. Однако, как написать сценарий конфигурирования для программы не обсуждается и не входит в рамки этой книги. Если читатель заинтересован в написании скрипта конфигурирования, обратитесь, пожалуйста, к системе конфигурирования GNU на www.gnu.org.

Все программы, которые используют систему конфигурирования сборки от GNU, поставляют скрипт оболочки, называемый configure, и несколько файлов поддержки, а также исходные тексты программ. Любой проект для Linux, который использует  систему конфигурирования сборки от GNU, требует для процесса сборки этот набор вспомогательных файлов. Наряду с набором файлов, который сопровождает данный дистрибутив статически, есть файлы, создаваемые динамически во время процесса сборки. Ниже описаны оба эти набора файлов.

Файлы, которые входят в состав дистрибутива, включают configure, Makefile.in и config.in. configure это сценарий оболочки. Чтобы увидеть различные параметры, которые он принимает, используйте ./configure --help. Сценарий configure по сути содержит ряд программ и тестов, которые будут выполнены на базовой системе, на основе которых изменяются входные данные для сборки. Чтобы читатель понял типы тестов, выполняемые configure, ниже перечислены некоторые обычно выполняемые проверки.

▪Проверка на существование заголовочных файлов, таких как stdlib.h, unistd.h, и так далее

▪Проверка на наличие интерфейсов библиотеки, таких как strcpy, memcpy, и так далее

▪Получение размера типа данных, такого как sizeof(int), sizeof(float), и так далее

▪Проверка/определение размещения наличия других внешних библиотек, необходимых для программы. Например, libjpeg для поддержки JPEG, или libpng для поддержки PNG

▪Проверка, соответствуют ли номера версий библиотек

Обычно есть зависимости, которые делают программу зависящей от системы. Создание скрипта configure, осведомлённого об этих зависимостях, будет гарантировать, что программа станет переносимой между платформами UNIX. Для выполнения вышеперечисленных задач configure использует два основных метода:

▪Пробная сборка тестовой программы: это используется там, где configure должен найти наличие заголовка или API, или библиотеки. Чтобы обнаружить присутствие stdlib.h, configure просто использует простую программу, похожую на показанную ниже.
 
#include <stdlib.h>
main() {
 return 0;
}
 
Если вышеописанная программа компилируется успешно, это свидетельствует о наличии годного к употреблению stdlib.h. Подобные тесты проводятся и для обнаружения присутствия API и библиотек.

▪Выполнение тестовой программы и получение выходного значения: в ситуациях, когда configure должен получить размер типа данных, единственным доступным методом является компиляция, выполнение и получение результата работы программы. Например, чтобы найти размер целого числа на платформе, выполняется приведённая ниже программа
 
main() {
 return sizeof(int)
};
 

Результат работы тестов/программ, выполняемых configure, обычно хранится в виде конфигурационного (препроцессорного) макроса config.h, и, если его создание было успешно завершено, configure начинает создание Makefile-ов. Эти конфигурационные макросы могут быть использованы в коде для выбора части кода, необходимого для конкретной платформы UNIX. Скрипт конфигурации принимает много входных аргументов; их можно узнать, запустив configure с параметром -help.

Для создания во время сборки Makefile, скрипт configure работает с Makefile.in. В каждом подкаталоге программы будет один такой файл. Конфигурационный скрипт также преобразует config.in в config.h, который изменяет CFLAGS, определённые для компиляции. Определение CFLAGS зависит от базовой системы, на которой выполняется процесс сборки. Большинство вопросов переносимости решается с помощью макросов препроцессора, которые получают определения в этом файле.

Файлы, создаваемые во время сборки приложения:

▪Makefile: это файл, который будет использовать make для сборки программы. Makefile.in в Makefile преобразует конфигурационный скрипт.

▪config.status: скрипт configure создаёт файл config.status, который является сценарием оболочки. Он содержит правила для повторной генерации генерируемых файлов и запускается автоматически, когда изменяется любой из входных файлов. Например, возьмём случай, когда у вас уже есть предварительно сконфигурированная директория для сборки (то есть такая, в которой хотя бы один раз был выполнен скрипт конфигурации). Теперь, если вы измените Makefile.in, то когда вы просто выполните команду make, получите созданные автоматически Makefile-ы. Повторная генерация происходит с помощью этого скрипта, без обращения к скрипту configure.

▪config.h: этот файл определяет конфигурацию макросов препроцессора, которую код языка Си может использовать для изменения своего поведения на различных системах.

▪config.cache: configure кэширует в этом файле результаты работы между запусками скрипта. В этом файле сохраняются выходные результаты различных этапов настройки. Каждая строка имеет вид присвоения переменная = значение.Переменная представляет собой имя, созданное сценарием, которое используется configure во время сборки. Прежде чем приступить к фактической проверке базовой машины, конфигурационный скрипт зачитывает значения переменных в этом файле в память.

▪config.log: он хранит выходные данные работы сценария конфигурирования. Опытные пользователи configure могут использовать этот скрипт, чтобы обнаружить проблемы с процессом конфигурации.