Создаем порт для FreeBSD своими руками. Часть I
Шрифт:
• Решение о присвоении программе определенной категории.
• Любимый текстовый редактор.
• Терпение и свободное время - возможно, порт придется пересобирать не один раз и даже не десять.
Первый порт - несложная программа для КDЕ
Мы не будем заниматься искуственными примерами. В качестве примера первого порта возьмем несложную программу для KDE, взятую с сайтаПочему именно для KDE? Сообщество разработчиков KDE огромно, программы появляются, развиваются, а потом перестают поддерживаться и развиваться постоянно, причем большинство их авторов из Европы, работающие в той или иной версии Linux и даже и не подозревающие, что их программа может работать и в другой операционной системе, и ситуация, когда на KDE applications находится
3
# make install >& install.log
В данном примере для перенаправления в файл и обьединения выводов stdout и stderr используется синтаксис tcsh, в sh необходимо выполнить:
# make install > install.log 2» install.log
Начинаем. Сразу же необходимо иметь в виду, что существует довольно жесткий порядок, в котором в файле Makefile должны появляться определения переменных. В нижеследующем примере приводится правильный порядок и нарушать его не рекомендуется.
Файл Makefile
В соответствии с рекомендациями [ 4 ] Makefile должен иметь следующий заголовок:
# New ports collection makefile for: contactsmenu
# Date created: 01 Mar 2006
# Whom: Rashid N. Achilov shelton@granch.ru
#
# $FreeBSD$
На этом заголовок кончается.
Внимание! Для впервые отправляемого порта строка $FreeBSD$ должна выглядеть именно так, как показана!
4
Руководство FreeBSD по созданию портов – http://www.ru.freebsd.org/doc/ru_RU.KOI8-R/books/porters-handbook/index.html.
Первыми строками, идущими за заголовком, должны быть следующие:
PORTNAME= contactsmenu
PORTVERSION= 0.3.4b
CATEGORIES= mail kde
Эти три переменные должны идти первыми и именно в том порядке, в котором они приведены. Первая из них задает имя порта. Она должна совпадать с именем каталога с файлами порта. Вторая задает номер текущей версии программы. Именно по ней будет проводится сравнение существующей и установленной версий. Третья перечисляет список категорий, к которым относится данный порт. Выбор категории, а также требования к составлению данного списка приведены в [2].
MASTER SITES= http://www.kde-apps.org/content/files/
Эта переменная должна идти сразу после CATEGORIES. Она задает список сайтов, с которых будет скачиваться дистрибутив программы.
Откуда взять имя дистрибутива и адрес домашнего сайта проекта? Как правило, первоначальная закачка файла производится вручную, следовательно, имя файла и URL исходного сайта всегда можно найти в логах программ, которыми он закачивался. Можно использовать для этого и другие методы, которые я не буду здесь описывать ввиду их чрезвычайно большого разнообразия. Таким образом, если бы имя дистрибутивного файла нашей программы было contactsmenu-0.3.4b.tar.gz, нам бы больше ничего не потребовалось указывать - вся информация для загрузки уже предоставлена. Но не все так просто, потому что имя нашего файла - 34479-contactsmenu-0.3.4b.tar.bz2.
Что делать? Для таких случаев предусмотрено принудительное задание имени дистрибутивного файла, которое должно быть полным, то есть
DISTNAME= 34479-${PORTNAME}-${PORTVERSION}
Включив в нижеследующие секции «USE_BZIP2=YES» мы сформировали полное имя дистрибутивного файла.
Для многих популярных URL типа www.apahe.org, sourceforge.net, www.kde.org
и пр. определены специальные макросы, в которых перечислены все URL, на которых можно найти данную программу. Например, если бы данная программа располагалась на сайте sourceforge.net, то строка MASTER_SITES была бы заменена следующей комбинацией:MASTER_SITES= ${MASTER_SITE_SOURCEFORGE}
MASTER SITE SUBDIR= contactsmenu
что означало бы загрузку файла с сайтов, входящих в заранее определенный список из подкаталога contactsmenu.
MAINTAINER= shelton@granch.ru
COMMENT= KDE 3.x addressbook Kicker applet
Эти строки должны идти в том порядке, в котором приведены. MAINTAINER задает адрес электронной почты лица, которое создало и управляет данным портом. COMMENT содержит краткое (одну строчку) описание данного порта.
Внимание! При использовании нескольких адресов электронной почты в поле MAINTAINER должен быть проставлен тот адрес, который будет указан в поле From: во время отправки подготовленных файлов порта командой send-pr. Если в поле MAINTAINER будет указан один адрес, а обновления порта пойдут с другого адреса, придется дополнительно подтверждать, что данное письмо отправлено именно майнтайнером порта, а не является подделкой.
USE_KDEBASE_VER= 3
USE_GMAKE= yes
USE BZIP2= yes
Начинается секция переменных USE_*. Здесь, как правило, перечисляются неявные зависимости, заранее определенные в системе. USE_KDEBASE задает зависимость порта от пакета kdebase3, USE_GMAKE - от пакета gmake, USE_BZIP2 - от пакета bzip2 (и заодно устанавливает EXTRACT_SUFX в «.tar.bz2»).
Что означает «порт X зависит от порта Y»? Это означает, что в соответствии с тем, к какому типу будет отнесена данная зависимость (EXTRACT_DEPENDS, RUN_DEPENDS и т. д., см. bsd.port.mk для полного списка), то на данном этапе построения порта (extract, install и т. д.) система проверит наличие установленного пакета, который указан как зависимость, и если он не установлен, система автоматически перейдет к его установке. В этом проявляется еще одно преимущество системы портов - имея скоростной канал в Интернете и дешевый трафик, можно не думать, например, о том, какие файлы нужны для установки KDE - достаточно перейти в каталог x11/kde и набрать make. Построение правильного списка зависимостей - одна из задач автора порта. Если указать ненужные программы - порт будет пытаться их поставить, что будет забивать систему мусором, если же забыть нужные - порт в лучшем случае не соберется, в худшем - соберется и не будет работать.
GNU_CONFIGURE= yes
CONFIGURE_ARGS += --with-qt-dir=${QT_PREFIX} \
– -with-extra-includes=${LOCALBASE}/include \
– -with-extra-libs=${LOCALBASE}/lib
Эти строки должны присутствовать (если они есть) после всех переменных USE_*. Они определяют, что для создания Makefile, управляющего сборкой программы, будет использоваться configure, и задают дополнительные аргументы, передаваемые при вызове configure. При сборке программы configure получает неявные параметры, задаваемые, например, с помощью PREFIX, но может получать и явные параметры, перечисляемые выше.
Ну и последней строкой нашего Makefile обязательно должна быть:
.include <bsd.port.mk>
которая, собственно, и загрузит основной файл. Вот и все, файл, управляющий сборкой программы создан.
Файл pkg-plist
Файл составляется как раз на основе протокола инсталляции install.log, который был сохранен во время установки программы. Следует также учесть, что программы для KDE часто используют локальные скрипты libtool, которые устанавливают динамические библиотеки, используя свои собственные конфигурационные файлы с расширением .la. Поэтому, если в протоколе установки упоминается, например, kickermenu_contactsmenu.la, нужно открыть его (это текстовый файл) и посмотреть, какая же библиотека там используется. Как правило, ее имя совпадает с именем .la файла (в нашем случае kickermenu_contactsmenu.so), но могут быть отличия, в частности, файлов может быть несколько. В файл pkg-plist компоненты программы вписываются по одному в строке, с указанием пути относительно корня установки (по умолчанию /usr/local).