Система сборки программ, используемая во FreeBSD, имеет значительно большие возможности, чем те, которые мы задействовали. Какие это возможности и как их использовать в своих портах?
Рашид Ачилов
Создаем порт для FreeBSD своими руками
Часть II: расширенные возможности
Расширенные возможности системы
Скромный размер нашего первого порта и его достаточная простота не позволила нам рассмотреть все возможности системы портов. В этом опять же проявляется ее достоинство — не нужно знать много для построения сравнительно простого порта. Но зачастую бывает так, что необходимо реализовать некую собственную функцию по обработке исходного текста или проверить наличие некоторой программы до начала установки своей. Сразу же возникает вопрос — пытаться реализовать это своими силами или же это уже было кем-то когда-то реализовано?
Расширенные возможности системы сборки портов, которые мы не использовали в первой части и которые можно использовать, это:
• Многофайловые дистрибутивы с возможностью отбора файлов в зависимости от заданного набора переменных.
• Внешние патчи, которые можно подключать в зависимости от заданного набора переменных.
• Задание параметров сборки порта с помощью полноэкранного текстового режима OPTIONS, с возможностью дальнейшего хранения и редактирования этих параметров.
Многофайловые дистрибутивы и внешние патчи
Обычно программа состоит всего из одного файла архива. Но порт зачастую состоит не только из архива исходных текстов программы — в него могут входить дополнительные архивы, файлы данных, файлы драйверов, дополнительные файлы, используемые в процессе построения. Хорошо, конечно, когда есть свой собственный ftp-сервер, в надежности которого не сомневаешься.
В этом случае файлы дистрибутива просто перечисляются:
DISTFILES= file1.tar.bz2 \
file2.tar.bz2 \
Опции
Если программа сложная, то, как правило она предлагает множество различных вариантов построения — с использованием такой-то возможности, без использования такой-то возможности… Некоторые порты сначала проводят «автоматическое обнаружение» некоторых задействуемых компонент, а уже потом устанавливают переменные, включающие или отключающие различные возможности, а некоторые оставляют это на усмотрение пользователя. Если пользователь об этом не подозревает, то он может так никогда ими и не воспользоваться. Одним из примеров того, как делать ни в коем случае не надо, я считаю порт graphics/ImageMagick. Мало того, что там 26 переменных, так еще пользователь даже не оповещается, что они вообще есть!
Рисунок 1.
Появилась возможность задавать опции в полноэкранном текстовом режиме
Mountsmb2
Набор скриптов mountsmb2 (там их три) был написан мной достаточно давно и преследовал тольк одну цель — автоматически монтировать SMB/CIFS-сетевые ресурсы от других Samba-серверов и компьютеров под управлением Windows. Поскольку это скрипт, написанный на языке командной оболочки sh, то никакой сборки порта не требуется и именно поэтому этот порт будет рассмотрен в качестве примера.
PORTNAME= mountsmb2
PORTVERSION= 0.90.1
CATEGORIES= sysutils net
Модификация порта OpenOffice 1.1.4
С моей точки зрения, порт для сборки OpenOffice editors/openoffice имел множество недостатков, но эти изменения я никогда не пробовал отправить во FreeBSD Team для помещения их в дерево портов. Какие изменения были внесены мной:
• возможность отказаться от сборки Mozilla Suite, нужной только для работы с адресной книгой формата Mozilla;
• возможность загрузить и применить последний (на тот момент) файл локализации интерфейса;
• возможность загрузить и применить внешние патчи, созданные в «Инфра-Ресурс» для версии для Linux.
Порт на самом деле состоит из двух файлов — editors/openoffice-1.1 и russian/openoffice. Makefile порта russian/openoffice-1.1 достаточно прост: