MASTER_SITES= http://www.foobar.com/:foobar,DEFAULT
Один и тот же файл может входить в несколько групп. Равным образом в одну группу могут входить несколько файлов. Естественно, допускается использование подстановки переменных:
GSI_VERSION= 2005-01-20
DISTFILES+= gsi-$(GSI_VERSION)-sorted.txt.bz2:oorus,oorus2
INFRA_PATCHEXT= OOo_1.1.4_infra_patches
DISTFILES+= ${INFRA_PATCHEXT}.tar.gz:DEFAULT,oorus
MASTER_SITES+= http://ootrans.i-rs.ru/out/:oorus
MASTER_SITES+= ftp://ftp.i-rs.ru/pub/openoffice/1.1.4/ru/:oorus2
MASTER_SITES+= ftp://ftp/granch.ru/pub/openoffice
В данном фрагменте файл gsi-2005-01-20-sorted.txt.bz2 будет скачиваться сначала с http://ootrans.i-rs.ru/out, потом с ftp://ftp.i-rs.ru/pub/openoffice/1.1.4/ru, а файл OOo_1.1.4_infra_patches.tar.gz – сначала с ftp://ftp.i-rs.ru/pub/openoffice/1.1.4/ru, потом с ftp://ftp.granch.ru/pub/openoffice.
Когда стоит пользоваться такой возможностью? Когда порт может состоять из большого количества файлов и хочется сделать возможность обойтись без загрузки файлов, которые не нужны.
Например, это не было сделано в порту editors/openoffice-1.1, и в результате чего исходные тексты Mozilla Suite (обьема немалого – 35 Мб) загружались независимо от желания пользователя ее использовать.
Использование внешних патчей во многом похоже на загрузку файлов исходного кода программы, только здесь используются переменные PATCH_SITES и PATCHFILES:
PATCH_SITES= ftp://ftp.cis.upenn.edu/pub/xv/
PATCHFILES= ${DISTNAME}.JPEG-patch ${DISTNAME}.TIFF-patch \
croppad.patch grabpatch vispatch \
deepcolor.patch gifpatch exceed_grab.patch \
tiff1200.patch gssafer.patch
Имейте в виду, что патчи, заданные в PATCHFILES, применяются до применения патчей из подкаталога files! То есть последовательность действий будет выглядеть так:
===> Patching for xv-3.10a_5
===> xv-3.10a_5 depends on file: /usr/local/bin/perl5.8.7 - found
===> Applying distribution patches for xv-3.10a_5
===> Applying FreeBSD patches for xv-3.10a_5
Когда стоит использовать внешние патчи? Разработчики обычно используют их, чтобы избежать выпуска нового релиза программы (так обычно поступают разработчики Squid – вместо выпуска нового релиза они выкладывают патчи значительного обьема), авторы портов, не являющиеся разработчиками программы, – чтобы внести в исходный текст изменения, с которыми автор может быть не согласен, если они достаточно обьемные и их нельзя поместить непосредственно в дерево портов, для расширения функциональности и т. д.
Следует учесть то, что если патч не создан с использованием стандартной процедуры diff, то его нельзя применять описанным методом и необходимо предусмотреть для него специальную обработку (см. пример в описании порта для OpenOffice).
Опции
Если программа сложная, то, как правило она предлагает множество различных вариантов построения – с использованием такой-то возможности, без использования такой-то возможности... Некоторые порты сначала проводят «автоматическое обнаружение» некоторых задействуемых компонент, а уже потом устанавливают переменные, включающие или отключающие различные возможности, а некоторые оставляют это на усмотрение пользователя. Если пользователь об этом не подозревает, то он может так никогда ими и не воспользоваться. Одним из примеров того, как делать ни в коем случае не надо, я считаю порт graphics/ImageMagick. Мало того, что там 26 переменных, так еще пользователь даже не оповещается, что они вообще есть!
Рисунок 1. Появилась возможность задавать опции в полноэкранном текстовом режиме
В результате строка запуска сборки порта может выглядеть, например,таким образом:
# make WITHOUT_IMAGEMAGICK_JPEG=yes WITH_WINDOWS_FONT_DIR=/tmp/blabla WITHOUT_IMAGEMAGICK_PNG=yes WITHOUT_IMAGEMAGICK_BZIP2=yes ...
Кроме того, что это просто очень долго набирать, попробуйте-ка вспомнить, какие там опции задавались при предыдущей сборке полгода назад? Разумеется, это крайне неудобно, и некоторое время назад в системе появилась возможность задавать опции в полноэкранном текстовом режиме (см. рис. 1).
Все опции, перечисленные на экране, задаются и отменяются простым нажатием пробела, результат выбора будет сохранен и использован при последующих сборках порта. В любое время его можно изменить, выполнив команду:
# make config
Формируется экран опций следующей командой в Makefile:
OPTIONS= LDAP "With LDAP support" on \
ADS "With Active Directory support" off \
CUPS "With CUPS printing support" on \
WINBIND "With WinBIND support" on \
ACL_SUPPORT "With ACL support" off \
SAM_XML "SAM with XML support" off
Первый параметр задает имя опции, которое потом будет использовано в переменной WITH_*. Например, для первого параметра имя переменной будет WITH_LDAP. Второй параметр задает текст комментария, который будет выведен справа от соответствующей опции, и третий – значение по умолчанию. При указании «on» опция по умолчанию включена, при указании «off» – выключена.
Хорошо, опции заданы. Как их обработать?
Прежде всего необходимо отметить, что при использовании OPTIONS включение файла bsd.port.mk следует заменить на:
.include <bsd.port.pre.mk>
# processing WITH_SOMEWHERE here
.include <bsd.port.post.mk>
иначе ни одна переменная WITH_SOMEWHERE распознана не будет. Обработка же переменных выполняется стандартным образом – с помощью условия if задаются дополнительные параметры для configure, зависимости, подстановки для pkg-plist и т. д.
.if defined(WITH_SAM_XML)
LIB_DEPENDS+= xml2.5:${PORTSDIR}/textproc/libxml2
CONFIGURE_ARGS+= --with-xml-prefix=${LOCALBASE}
WANT_EXPSAM_MODULES+= xml
PLIST_SUB+= SAMXML=""
.else
PLIST_SUB+= SAMXML="@comment "