Diese enthält eine längere Beschreibung des Ports. Einer oder mehrere Absätze, die kurz und prägnant erklären, was der Port macht, sind ausreichend.

Das folgende Beispiel zeigt wie Ihre pkg-descr aussehen sollte:

This is a port of oneko, in which a cat chases a poor mouse all over
the screen.
 :
(etc.)

WWW: http://www.oneko.org/

Diese Datei enthält eine Liste aller Dateien, die von diesem Port installiert werden. Sie wird auch die „Packliste“ genannt, da das Paket durch die hier aufgeführten Dateien erstellt wird. Die Pfadangaben sind relativ zum Installationspräfix (für gewöhnlich /usr/local oder /usr/X11R6). Wenn Sie die MANn-Variablen verwenden (was Sie auch machen sollten), führen Sie hier keine Manualpages auf. Wenn der Port während der Installation Verzeichnisse erstellt, stellen Sie sicher entsprechende @dirrm-Zeilen einzufügen, um die Verzeichnisse zu entfernen, wenn das Paket gelöscht wird.

Hier ist ein kleines Beispiel:

bin/oneko
lib/X11/app-defaults/Oneko
lib/X11/oneko/cat1.xpm
lib/X11/oneko/cat2.xpm
lib/X11/oneko/mouse.xpm
@dirrm lib/X11/oneko

Für weitere Details zur Packliste lesen Sie in der pkg_create(1) Manualpage nach.

Es gibt nur einen Fall, in dem pkg-plist weggelassen werden kann. Wenn der Port nur eine handvoll Dateien und Verzeichnisse installiert, können diese in den Variablen PLIST_FILES und PLIST_DIRS im Makefile aufgelistet werden. Zum Beispiel könnten wir im obigen Beispiel ohne pkg-plist für den oneko-Port auskommen, indem wir die folgenden Zeilen ins Makefile einfügen:

PLIST_FILES=    bin/oneko \
                lib/X11/app-defaults/Oneko \
                lib/X11/oneko/cat1.xpm \
                lib/X11/oneko/cat2.xpm \
                lib/X11/oneko/mouse.xpm
PLIST_DIRS=     lib/X11/oneko

Natürlich sollte PLIST_DIRS ungesetzt bleiben, wenn der Port keine eigenen Verzeichnisse installiert.

Der Preis für diese Art die Dateien eines Ports anzugeben ist, dass man keine Befehlsfolgen wie in pkg_create(1) nutzen kann. Deshalb ist es nur für einfache Ports geeignet und macht diese noch einfacher. Gleichzeitig bringt es den Vorteil die Anzahl der Dateien in der Ports-Sammlung zu reduzieren. Deshalb ziehen Sie bitte diese Vorgehensweise in Erwägung, bevor Sie pkg-plist benutzen.

Später werden wir uns ansehen, wie pkg-plist und PLIST_FILES benutzt werden können, um anspruchsvollere Aufgaben zu erfüllen.

Setzen Sie bitte die Variable PORTNAME auf den Basisnamen Ihres Ports und die Variable PORTVERSION auf dessen Versionsnummer.

Zwei optionale Variablen, PKGNAMEPREFIX und PKGNAMESUFFIX, werden verknüpft mit PORTNAME und PORTVERSION, um PKGNAME zu bilden als ${PKGNAMEPREFIX}${PORTNAME}${PKGNAMESUFFIX}-${PORTVERSION} . Stellen Sie bitte unbedingt sicher, dass diese Variablen den Richtlinien für einen guten Paketnamen entsprechen. Insbesondere dürfen Sie keinesfalls einen Bindestrich (-) in PORTVERSION verwenden. Falls das Paket den language- oder -compiled.specifics-Teil aufweist (siehe unten) benutzen Sie PKGNAMEPREFIX oder PKGNAMESUFFIX respektive. Machen Sie diese Variablen nicht zum Bestandteil von PORTNAME!

Die Umgebungsvariable LATEST_LINK wird während der Paketerstellung verwendet, um einen Kurznamen festzulegen, der danach von pkg_add -r genutzt werden kann. Dadurch wird es beispielsweise möglich, die aktuelle Perl-Version durch einen einfachen Aufruf von pkg_add -r perl zu installieren (ohne die Angabe der korrekten Versionsnummer). Dieser Name muss eindeutig sowie „offensichtlich“ sein.

In einigen Fällen können mehrere Versionen einer Applikation gleichzeitig in der Ports-Sammlung sein. Das index build- und das package build-System müssen nun in der Lage sein, diese als unterschiedliche Ports zu erkennen, obwohl diese Versionen alle die gleichen Variablen PORTNAME, PKGNAMEPREFIX und sogar PKGNAMESUFFIX aufweisen. In solchen Fällen sollte die optionale Variable LATEST_LINK auf einen unterschiedlichen Wert für alle Ports gesetzt werden mit Ausnahme des „Haupt-Ports“. Beispiele hierfür sind die lang/gcc46 und lang/gcc-Ports und die www/apache*-Familie. Wenn Sie die Umgebungsvariable NO_LATEST_LINK setzen, wird kein Link erzeugt, was für alle Versionen (aber nicht für die „Hauptversion“) nützlich sein kann. Beachten Sie bitte, dass die Frage der Auswahl der „wichtigsten“ Version („am populärsten“, „am besten Unterstützt“, „zuletzt gepatcht“ usw.) ausserhalb der Möglichkeiten dieses Handbuches liegt. Wir sagen Ihnen nur, wie Sie die anderen Ports spezifizieren, nachdem Sie den „Haupt-Port“ erkoren haben.

Im Folgenden finden Sie die Regeln für die Benennung Ihrer Pakete. Diese sollen gewährleisten, dass das Paketverzeichnis leicht zu durchsuchen ist, da es bereits abertausende Pakete gibt und die Nutzer sich mit Schauder abwenden, wenn Ihre Augen überstrapaziert werden!

Der Paketname soll aussehen wie language_region-name-compiled.specifics-version.numbers.

Der Paketname ist definiert als ${PKGNAMEPREFIX}${PORTNAME}${PKGNAMESUFFIX}-${PORTVERSION} . Stellen Sie bitte sicher, dass die Variablen Ihres Ports diesem Format entsprechen.

Hier sind einige reale Beispiele, die aufzeigen, wie man den Namen einer Applikation zu einem vernünftigen Paketnamen umwandelt:

Falls es in der Originalquelle überhaupt keinen Anhaltspunkt für irgendeine Versionsbezeichnung gibt und es unwahrscheinlich ist, dass der Autor jemals eine neue Version veröffentlichen wird, dann setzen Sie bitte die Version einfach auf 1.0 (wie im obigen Beispiel piewm). Sie können auch den Autor fragen oder eine Datumszeichenfolge in der Art 0.0.yyyy.mm.dd als Version verwenden.

Wenn ein Paket erzeugt wird, dann wird es unter /usr/ports/packages/All abgelegt und von einem oder mehreren Unterverzeichnissen werden auf /usr/ports/packages Links erstellt. Die Namen dieser Unterverzeichnisse werden durch die Variable CATEGORIES festgelegt. Dies geschieht, um dem Nutzer zu helfen, eine große Zahl von Paketen auf einer FTP-Webseite oder einer CD/DVD zu durchsuchen. Bitte werfen Sie einen Blick auf die Aktuelle Liste der Kategorien und suchen Sie die beste Kategorie für Ihren Port aus.

Diese Liste legt auch fest, an welcher Stelle in der Ports-Sammlung der Port eingefügt wird. Falls Sie mehrere Kategorien angeben wird angenommen, dass die Dateien des Ports im Unterverzeichnis mit dem Namen der ersten angegebenen Kategorie liegen. Schauen Sie bitte unten für weitere Informationen darüber, wie man die richtige Kategorie bestimmt.

Hier ist die aktuelle Liste der Kategorien. Die mit einem Asterisk (*) bezeichneten sind virtuelle Kategorien, also solche, welche über kein eigenes Unterverzeichnis in der Ports-Sammlung verfügen. Sie werden nur als Sekundärkategorien benutzt und sind nur für Suchzwecke eingerichtet worden.

Da viele der Kategorien sich überlappen, müssen Sie oft festlegen, welches die primäre Kategorie Ihres Ports ist. Hierzu gibt es einige Regeln, welche diese Auswahl bestimmen. Hier ist die Liste der Regeln mit abnehmender Wichtigkeit:

Falls Sie sich über die Kategorie im Unklaren sind, hinterlassen Sie bitte einen Kommentar in Ihrem per send-pr(1) eingereichten Bericht, damit wir diese Frage vor dem Import diskutieren können. Falls Sie ein Committer sind, schicken Sie bitte eine Nachricht an FreeBSD ports, damit die Frage im Vorhinein erörtert werden kann. Neue Ports werden zu häufig falsch kategorisiert und werden sofort wieder verschoben. Das bläht das Master Source Repository unnötig auf.

Da die Ports-Sammlung über viele Jahre gewachsen ist, wurden viele neue Kategorien hinzugefügt. Neue Kategorien können virtuell (ohne eigenes Unterverzeichnis in der Ports-Sammlung) oder physisch sein. Der nachfolgende Text führt einige Punkte auf, welche bei der Neueinführung einer physischen Kategorie beachtet werden müssen, damit Sie dies bei einem eventuellen Vorschlag Ihrerseits berücksichtigen können.

Unsere bestehende Maxime ist die Vermeidung der Neuanlage von physischen Kategorien, solange nicht eine große Zahl von Ports zugeordnet werden können oder falls ihr nicht Ports zugehören würden, welche eine logisch abgegrenzte Gruppe von limitiertem öffentlichem Interesse zugehören würden (zum Beispiel neue Sprachkategorien) oder vorzugsweise beides.

Die Erklärung dafür ist, dass eine Neuanlage einer physischen Kategorie einen erheblichen Arbeitsaufwand sowohl für die Committer als auch diejenigen Nutzer bedeutet, welche die Änderungen der Ports-Sammlung nachvollziehen. Zusätzlich verursachen Vorschläge für neue Kategorien oftmals Kontroversen (natürlich deswegen, weil es keinen klaren Konsens darüber gibt, welche Kategorie als „zu groß“ betrachtet werden muss noch ob sich bestimmte Kategorien zur einfachen Suche eignen (und wie viele Kategorien überhaupt ideal wären) und so weiter).

Hier ist das Prozedere:

Das Vorschlagen einer neuen virtuellen Kategorie ist ähnlich, aber wesentlich weniger aufwendig, weil keine Ports verschoben werden müssen. In diesem Falle müssen nur die Patches an den PR beigefügt werden, welche die neue Kategorie zur Variable CATEGORIES der betroffenen Ports hinzufügen.

Von Zeit zu Zeit schlägt jemand eine komplette Neuorganisation aller Ports, entweder mit einer zweistufigen Struktur oder irgendeiner Art von Schlüsselwörtern, vor. Bis heute wurde keiner dieser Vorschläge umgesetzt, weil sie zwar einfach zu machen sind, aber der Aufwand zur Umsetzung und Reorganisation der kompletten Ports-Sammlung schlichtweg mörderisch wäre. Bitte lesen Sie die Geschichte dieser Vorschläge in den Archiven der Mailinglisten nach, bevor Sie diese Ideen nochmals unterbreiten. Zudem sollten Sie gewappnet sein, dass man Sie auffordert, einen arbeitsfähigen Prototyp vorzulegen.

DISTNAME ist der Name der Applikation wie er von den Autoren vergeben wurde. DISTNAME hat als Vorgabe ${PORTNAME}-${PORTVERSION} also überschreiben Sie diese Vorgabe nur, wenn es notwendig ist. DISTNAME wird nur an zwei Stellen genutzt. Erstens: (DISTFILES) hat als Vorgabe ${DISTNAME}${EXTRACT_SUFX}. Zweitens: Die Distributionsdatei soll in einem Unterverzeichnis namens WRKSRC extrahiert werden, dessen Vorgabe work/${DISTNAME} ist.

Manche Drittanbieter-Namen, welche nicht in das Schema ${PORTNAME}-${PORTVERSION} passen, können durch Setzen von DISTVERSION automatisch behandelt werden. PORTVERSION und DISTNAME werden automatisch abgeleitet, können aber natürlich manuell überschrieben werden. Die folgende Tabelle führt einige Beispiele auf:

Dokumentieren Sie das Verzeichnis der FTP/HTTP-URL, welche auf den originalen Tarball zeigt, in der Variable MASTER_SITES. Bitte vergessen Sie niemals den Schrägstrich (/) am Ende!

Die make-Makros werden versuchen, diese Festlegung für die Aufbereitung der Distributionsdateien mittels FETCH zu benutzen, falls sie diese nicht schon auf dem System finden.

Es wird empfohlen, mehrere Webseiten in dieser Liste aufzuführen, vorzugsweise auf verschiedenen Kontinenten. Dies ist ein Schutz gegen Probleme bei größeren Ausfällen im Internet. Wir planen sogar Unterstützung einzubauen, die automatisch einen Server in der Nähe zum Herunterladen bestimmt. Die Verfügbarkeit von vielen Webseiten wird dieses Vorhaben beträchtlich erleichtern.

Falls der originale Tarball Teil eines populären Archivs ist, wie SourceForge, GNU oder Perl CPAN, können Sie möglicherweise auf diese Seiten in einer einfachen und kompakten Form mittels MASTER_SITE_* (d.h., MASTER_SITE_SOURCEFORGE,, MASTER_SITE_GNU und MASTER_SITE_PERL_CPAN) referenzieren. Setzen Sie einfach MASTER_SITES auf eine dieser Variablen und MASTER_SITE_SUBDIR auf den Pfad innerhalb des Archivs. Hier ist ein Beispiel:

MASTER_SITES=         ${MASTER_SITE_GNU}
MASTER_SITE_SUBDIR=   make

Oder verwenden Sie ein kondensiertes Format:

MASTER_SITES=   GNU/make

Diese Variablen werden in /usr/ports/Mk/bsd.sites.mk definiert. Es werden ständig neue Einträge hinzugefügt, daher stellen Sie bitte unbedingt sicher, dass Sie die neueste Version verwenden, bevor Sie einen Port einschicken.

Für beliebte Seiten existieren sogenannte magic-Makros, die eine bestimmte Verzeichnisstruktur erstellen. Um eines dieser Makros zu verwenden, geben Sie dessen Abkürzung an und Ihr System wird versuchen, das korrekte Unterverzeichnis automatisch zu bestimmen.

MASTER_SITES=	SF

Ist das Ergebnis nicht korrekt, können Sie diesen Wert auch überschreiben.

MASTER_SITES=	SF/stardict/WyabdcRealPeopleTTS/${PORTVERSION}

Falls Sie eine Distributionsdatei haben, die ein eigentümliches Suffix nutzt, um die Art der Kompression anzuzeigen, dann setzen Sie EXTRACT_SUFX.

Ist die Distributionsdatei zum Beispiel im Stil von foo.tgz anstatt des normalen foo.tar.gz benannt, würden Sie schreiben:

DISTNAME=      foo
EXTRACT_SUFX=  .tgz

Falls erforderlich, setzen die Variablen USE_BZIP2 und USE_ZIP automatisch EXTRACT_SUFX auf .tar.bz2 oder .zip. Falls keine der beiden gesetzt ist, dann verwendet EXTRACT_SUFX die Vorgabe .tar.gz.

Manchmal haben die zu ladenden Dateien keinerlei Ähnlichkeit mit dem Namen des Ports. Es könnte z.B. source.tar.gz oder ähnlich heißen. In anderen Fällen könnte der Quelltext in mehreren Archiven sein und alle müssen heruntergeladen werden.

Falls dies der Fall ist, setzen Sie DISTFILES als eine durch Leerzeichen getrennte Liste aller Dateien, die geladen werden müssen.

DISTFILES=     source1.tar.gz source2.tar.gz

Wenn nicht ausdrücklich gesetzt, verwendet DISTFILES als Vorgabe ${DISTNAME}${EXTRACT_SUFX}.

Falls nur einige der DISTFILES extrahiert werden müssen (z.B. eine Datei ist der Quelltext und eine andere ist ein unkomprimiertes Dokument), dann listen Sie die zu extrahierenden Dateien in EXTRACT_ONLY auf.

DISTFILES=     source.tar.gz manual.html
EXTRACT_ONLY=  source.tar.gz

Falls keine der DISTFILES unkomprimiert sein sollte, dann setzen Sie EXTRACT_ONLY auf einen leeren String.

EXTRACT_ONLY=

Falls Ihr Port zusätzliche Patches benötigt, welche per FTP oder HTTP verfügbar sind, dann setzen Sie PATCHFILES auf den Namen der Dateien und PATCH_SITES auf die URL des Verzeichnisses, das diese Patches enthält (das Format ist das gleiche wie MASTER_SITES).

Falls ein Patch wegen einiger zusätzlicher Pfadnamen nicht relativ zum Anfang des Quelltextbaumes (d.h., WRKSRC) liegt, dann setzen Sie bitte PATCH_DIST_STRIP entsprechend. Wenn z.B. alle Pfadnamen in diesem Patch ein zusätzliches foozolix-1.0/ vor ihren Dateinamen aufweisen, dann setzen Sie bitte PATCH_DIST_STRIP=-p1.

Kümmern Sie sich nicht darum, ob die Patches komprimiert sind. Sie werden automatisch dekomprimiert, wenn die Dateinamen auf .gz oder .Z enden.

Falls der Patch zusammen mit anderen Dateien in einem gezippten Tarball verteilt wird (z.B. mit Dokumentation), dann können Sie nicht PATCHFILES verwenden. In diesem Fall fügen Sie den Namen und den Ort dieses Tarballs zu DISTFILES und MASTER_SITES. Benutzen Sie dann die EXTRA_PATCHES-Variable, um auf diese Dateien zu zeigen und bsd.port.mk wird automatisch diese Dateien nutzen. Kopieren Sie niemals Patch-Dateien in das PATCHDIR-Verzeichnis, weil es möglicherweise nicht beschreibbar ist.

(Betrachten Sie es als in irgendeiner Form „fortgeschrittenes Thema“. Neulinge sollten möglicherweise diesen Abschnitt beim ersten Lesen überspringen).

Dieser Abschnitt stellt Informationen über die Mechanismen zum Herunterladen von Dateien zur Verfügung und behandelt die Variablen MASTER_SITES:n und MASTER_SITES_NN. Wir beziehen uns im weiteren Text auf diese Variablen als MASTER_SITES:n.

Etwas Hintergrundinformation zu Beginn: OpenBSD verfügt über eine sehr elegante Option innerhalb der Variablen DISTFILES und PATCHFILES. Sowohl Dateien als auch Patches können mit angehängten :n-Bezeichnern versehen werden wobei n in beiden Fällen [0-9] sein kann und eine Gruppenzugehörigkeit anzeigt. Ein Beispiel hierfür ist:

DISTFILES=      alpha:0 beta:1

In OpenBSD wird die Datei alpha mit der Variable MASTER_SITES0 verknüpft anstatt dem in FreeBSD gebräuchlichen MASTER_SITES und beta mit MASTER_SITES1.

Das ist eine sehr interessante Möglichkeit, die endlose Suche nach der richtigen Download-Seite zu verkürzen.

Stellen Sie sich zwei Dateien in DISTFILES und 20 Webseiten in der Variable MASTER_SITES vor. Alle Seiten sind erschreckend langsam, beta findet sich auf allen Seiten in MASTER_SITES und alpha kann nur auf der zwanzigsten Seite gefunden werden. Wäre es nicht reine Verschwendung, wenn der Maintainer alle Seiten zuvor überprüfen müsste? Kein guter Start für das wundervolle Wochenende!

Übertragen Sie diesen Umstand auf noch mehr DISTFILES und mehr MASTER_SITES. Ganz sicher würde unser „distfiles survey master“ die Erleichterung sehr zu schätzen wissen, die eine solche Verringerung der Netzwerkbelastung bringen würde.

In den nächsten Abschnitten sehen Sie die Implementierung dieser Idee durch FreeBSD. Dabei wurde das Konzept von OpenBSD ein wenig verbessert.

MASTER_SITES=   ftp://ftp.example1.com/:source1 \
	ftp://ftp.example2.com/:source2
DISTFILES=      source1.tar.gz:source1 \
	source2.tar.gz:source2

MASTER_SITES=   ftp://ftp.example1.com/:source1 \
	ftp://ftp.example2.com/:source2
DISTFILES=      source1.tar.gz:source1 \
	source2.tar.gz:source2 \
	source3.tar.gz:source2

Verhindern Sie, dass Ihr Port das Verzeichnis /usr/ports/distfiles in Unordnung bringt. Falls Ihr Port eine ganze Reihe von Dateien herunterladen muss oder eine Datei enthält, die einen Namen hat, der möglicherweise mit anderen Ports in Konflikt stehen könnte (d.h.Makefile), dann setzen Sie die Variable DIST_SUBDIR auf den Namen des Ports (${PORTNAME} oder ${PKGNAMEPREFIX}${PORTNAME} sollte hervorragend funktionieren). Dies wird DISTDIR von der Vorgabe /usr/ports/distfiles auf /usr/ports/distfiles/DIST_SUBDIR ändern und stellt tatsächlich alle für Ihren Port benötigten Dateien in dieses Unterverzeichnis.

Es wird zusätzlich nach dem Unterverzeichnis mit dem gleichen Namen auf der Sicherung der Hauptseite auf ftp.FreeBSD.org suchen (das ausdrückliche Setzen von DISTDIR in Ihrem Makefile wird dies nicht gewährleisten, also nutzen Sie bitte DIST_SUBDIR).

Falls Ihr Port binäre Distfiles benutzt und eine Lizenz aufweist, die verlangt, dass das der Quelltext in Form binärer Pakete verteilt werden muss, z.B. GPL, dann wird ALWAYS_KEEP_DISTFILES den FreeBSD Build Cluster anweisen eine Kopie der Dateien in DISTFILES vorzuhalten. Nutzer dieser Ports benötigen generell diese Dateien nicht, daher ist es ein gutes Konzept, nur dann die Distfiles zu DISTFILES hinzuzufügen, wenn PACKAGE_BUILDING definiert ist.

.if defined(PACKAGE_BUILDING)
DISTFILES+=             foo.tar.gz
ALWAYS_KEEP_DISTFILES=  yes
.endif

Wenn Sie zusätzliche Dateien zu DISTFILES hinzufügen, dann beachten Sie bitte, dass Sie diese auch in distinfo aufführen. Zudem werden die zusätzlichen Dateien normalerweise ebenso in WRKDIR extrahiert, was für einige Ports zu unbeabsichtigten Seiteneffekten führen mag und spezielle Behandlung erfordert.

Diese Variable spezifiziert die Shared-Libraries, von denen der Port abhängt. Es ist eine Liste von lib:dir[:target]-Tupeln wobei lib den Name der gemeinsam genutzten Bibliothek, dir das Verzeichnis, in welchem sie zu finden ist, falls nicht verfügbar, und target das Target in diesem Verzeichnis angeben. Zum Beispiel wird

LIB_DEPENDS=   jpeg.9:${PORTSDIR}/graphics/jpeg

auf eine jpeg-Bibliothek mit der Hauptversionsnummer 9 prüfen, in das graphics/jpeg-Unterverzeichnis Ihrer Ports-Sammlung wechseln, es bauen und installieren, falls es nicht gefunden wird. Der target-Teil kann weggelassen werden, falls er identisch mit DEPENDS_TARGET ist (Vorgabe hierfür ist install).

Die Abhängigkeit wird zwei Mal überprüft, einmal innerhalb des extract-Target und dann innerhalb des install-Target. Zudem wird der Name der Abhängigkeit in das Paket eingefügt, damit pkg_add(1) es automatisch installiert, falls es nicht auf dem Rechner des Nutzers ist.

Diese Variable legt Binärdateien oder Dateien, von denen der Port abhängt, für die Laufzeit fest. Es ist eine Liste von path:dir[:target]-Tupeln, wobei path der Name der Binärdatei oder Datei, dir das Verzeichnis, in welchem sie gefunden werden kann, falls nicht vorhanden, und target das Target in diesem Verzeichnis angeben. Falls path mit einem Slash (/) beginnt, wird es als Datei behandelt und deren Vorhandensein wird mit test -e; überprüft. Andernfalls wird angenommen, dass es eine Binärdatei ist und which -s wird benutzt, um zu überprüfen, ob das Programm im Pfad vorhanden ist.

Zum Beispiel wird

RUN_DEPENDS=   ${LOCALBASE}/etc/innd:${PORTSDIR}/news/inn \
	   xmlcatmgr:${PORTSDIR}/textproc/xmlcatmgr

überprüfen, ob die Datei oder das Verzeichnis /usr/local/etc/innd existiert und es erstellen und installieren aus dem news/inn-Unterverzeichnis der Ports-Sammlung, falls es nicht gefunden wird. Es wird zudem überprüft, ob die Binärdatei namens xmlcatmgr im Suchpfad vorhanden ist und danach zum Unterverzeichnis textproc/xmlcatmgr in Ihrer Ports-Sammlung wechseln, es bauen und installieren, falls es nicht gefunden wird.

/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin:/usr/X11R6/bin

Die Abhängigkeit wird innerhalb des install-Target überprüft. Zudem wird der Name der Abhängigkeit in das Paket übernommen, damit pkg_add(1) es automatisch installieren wird, falls es auf dem System des Nutzers nicht vorhanden ist. Der target-Teil kann weggelassen werden, wenn er der gleiche ist wie in der Variable DEPENDS_TARGET.

Es kommt recht häufig vor, dass RUN_DEPENDS genau dasselbe enthält wie BUILD_DEPENDS, gerade dann, wenn die portierte Software in einer Skriptsprache geschrieben ist oder dieselbe Umgebung, die zum Bau verwendet wurde, zur Laufzeit gebraucht wird. In diesem Fall ist es sowohl verlockend als auch intuitiv, den Wert der einen Variable der anderen direkt zuzuweisen:

RUN_DEPENDS= ${BUILD_DEPENDS}

Jedoch kann eine solche Zuweisung dazu führen, dass die Liste der Laufzeitabhängigkeiten mit überflüssigen Einträgen belastet wird, die sich nicht in der ursprünglichen Liste BUILD_DEPENDS des Ports befanden, da sich make(1) bei der Auswertung solcher Zuweisungen träge verhält. Stellen Sie sich ein Makefile mit USE_*-Variablen vor, die von ports/Mk/bsd.*.mk verarbeitet werden, um initiale Bauabhängigkeiten zusammenzutragen. Zum Beispiel fügt USE_GMAKE=yes devel/gmake zu BUILD_DEPENDS hinzu. Um zu verhindern, dass solche zusätzlichen Abhängigkeiten RUN_DEPENDS belasten, achten Sie darauf, bei gleichzeitiger Auswertung zuzuweisen, d.h. der Ausdruck wird ausgewertet, bevor er als Wert der Variablen zugewiesen wird:

RUN_DEPENDS:=  ${BUILD_DEPENDS}

Diese Variable legt Binärdateien oder Dateien fest, die dieser Port zur Erstellung benötigt. Wie RUN_DEPENDS ist es eine Liste von path:dir[:target]-Tupeln. Zum Beispiel wird

 BUILD_DEPENDS=
	  unzip:${PORTSDIR}/archivers/unzip

überprüfen, ob eine Binärdatei unzip vorhanden ist und in das Unterverzeichnis archivers/unzip Ihrer Ports-Sammlung wechseln und sie erstellen und installieren, falls sie nicht gefunden wird.

Diese Variable legt eine Binärdatei oder Datei fest, welche der Port benötigt, um heruntergeladen werden zu können. Wie die vorherigen beiden Variablen ist er eine Liste von path:dir[:target]-Tupeln. Zum Beispiel wird

 FETCH_DEPENDS=
	  ncftp2:${PORTSDIR}/net/ncftp2

überprüfen, ob eine Binärdatei namens ncftp2 vorhanden ist, in das Unterverzeichnis net/ncftp2 Ihrer Ports-Sammlung wechseln, sie erstellen und installieren, falls sie nicht gefunden wird.

Die Abhängigkeit wird innerhalb des fetch-Target überprüft. Der target-Teil kann weggelassen werden, falls er identisch mit der Variable DEPENDS_TARGET ist.

Diese Variable spezifiziert eine Binärdatei oder eine Datei, welche dieser Port für die Extraktion benötigt. Wie die vorherigen Variablen ist er eine Liste von path:dir[:target]-Tupeln. Zum Beispiel wird

EXTRACT_DEPENDS=
	  unzip:${PORTSDIR}/archivers/unzip

überprüfen, ob eine Binärdatei namens unzip vorhanden ist, in das Unterverzeichnis archivers/unzip Ihrer Ports-Sammlung wechseln, sie erstellen und installieren, falls sie nicht gefunden wird.

Die Abhängigkeit wird innerhalb des extract-Target überprüft. Der target-Teil kann weggelassen werden, falls er identisch mit der Variable DEPENDS_TARGET ist.

Diese Variable legt eine Binärdatei oder eine Datei fest, welche dieser Port zum Patchen benötigt. Wie die vorhergehenden Variablen ist diese eine Liste von path:dir[:target]-Tupeln. Zum Beispiel wird

 PATCH_DEPENDS=
	  ${NONEXISTENT}:${PORTSDIR}/java/jfc:extract
	  

in das Unterverzeichnis java/jfc Ihrer Ports-Sammlung wechseln, um es zu entpacken.

Die Abhängigkeit wird innerhalb des patch-Target überprüft. Der target-Teil kann entfallen, falls er identisch mit der Variable DEPENDS_TARGET ist.

Es gibt eine Reihe von Variablen, um gebräuchliche Abhängigkeiten einzukapseln, die viele Ports aufweisen. Obwohl Ihre Verwendung optional ist, können sie helfen die Übersichtlichkeit des Makefile eines Ports zu erhöhen. Jede von ihnen ist im Stil von USE_*. Der Gebrauch dieser Variablen ist beschränkt auf das Makefile eines Ports und ports/Mk/bsd.*.mk. Es ist nicht entworfen worden, um durch den Nutzer setzbare Optionen einzukapseln; benutzen Sie WITH_* und WITHOUT_* für diese Zwecke.

USE_GCC=3.4

Variablen zugehörig zu gmake und dem configure-Skript werden in Abschnitt 6.3, „Build-Mechanismen“ beschrieben, währenddessen autoconf, automake und libtool in Abschnitt 6.4, „Benutzung von GNU autotools“ beschrieben sind. Perl-spezifische Variablen werden in Abschnitt 6.6, „Die Benutzung von perl“ behandelt. X11-Variablen sind aufgelistet in Abschnitt 6.7, „Benutzung von X11“. Abschnitt 6.8, „Benutzung von GNOME“ behandelt GNOME-bezogene Variablen und Abschnitt 6.10, „Benutzung von KDE“ KDE-bezogene Variablen. Abschnitt 6.11, „Benutzung von Java“ dokumentiert Java-Variablen, während Abschnitt 6.12, „Webanwendungen, Apache und PHP“Informationen zu Apache, PHP und PEAR-Modulen enthält. Python wird in Abschnitt 6.13, „Python benutzen“ und Ruby in Abschnitt 6.16, „Ruby benutzen“ erörtert. Abschnitt 6.17, „SDL verwenden“ stellt Variablen für SDL-Programme zur Verfügung und Abschnitt 6.20, „Xfce verwenden“ enthält schliesslich Variablen für Xfce.

Eine minimale Version einer Abhängigkeit kann in jeder *_DEPENDS-Variable festgelegt werden mit Ausnahme von LIB_DEPENDS durch Anwendung folgender Syntax:

p5-Spiffy>=0.26:${PORTSDIR}/devel/p5-Spiffy

Das erste Feld enthält einen abhängigen Paketnamen, welcher einem Eintrag in der Paketdatenbank entsprechen muss und einen Vergleich mit einer Paketversion. Die Abhängigkeit wird erfüllt, wenn p5-Spiffy-0.26 oder eine neuere Version auf dem System installiert ist.

Wie vorstehend beschrieben ist das Vorgabe-Target DEPENDS_TARGET, wenn eine Abhängigkeit benötigt wird. Die Vorgabe hierfür ist install. Dies ist eine Nutzer-Variable; sie wird niemals im Makefile eines Ports definiert. Falls Ihr Port einen besonderen Weg benötigt, um mit einer Abhängigkeit umzugehen, dann benutzen Sie bitte den :target-Teil der *_DEPENDS-Variablen, anstatt DEPENDS_TARGET zu ändern.

Falls Sie make clean schreiben, werden dessen Abhängigkeiten auch gesäubert. Falls Sie dies nicht wollen, definieren Sie die Variable NOCLEANDEPENDS in Ihrer Umgebung. Dies kann besonders erstrebenswert sein, wenn der Port etwas in seiner Liste von Abhängigkeiten hat, das sehr viel Zeit für einen rebuild benötigt wie KDE, GNOME oder Mozilla.

Um von einem anderen Port bedingungslos abhängig zu sein, benutzen Sie bitte die Variable ${NONEXISTENT} als erstes Feld von BUILD_DEPENDS oder RUN_DEPENDS. Benutzen Sie dies nur, wenn Sie den Quelltext eines anderen Port benötigen. Sie können auch oft Kompilierzeit sparen, wenn Sie das Target festlegen. Zum Beispiel wird

BUILD_DEPENDS=   ${NONEXISTENT}:${PORTSDIR}/graphics/jpeg:extract

immer zum jpeg-Port wechseln und ihn extrahieren.

Die Struktur für die Erstellung von Ports dulde keinerlei zirkuläre Abhängigkeiten. Falls Sie dennoch eine verwenden, wird es irgendjemanden irgendwo auf der Welt geben, dessen FreeBSD-Installation nahezu sofort zusammenbricht und vielen anderen wird es sehr schnell genauso ergehen. So etwas kann extrem schwer festzustellen sein. Falls Sie Zweifel haben vor einer Änderung, dann vergewissern Sie sich, dass Sie folgendes getan haben: cd /usr/ports; make index. Dieser Prozess kann auf alten Maschinen sehr langsam sein, aber Sie ersparen sich und einer Vielzahl von Menschen möglicherweise eine Menge Ärger.

Wenn Sie ein GNU-Konfigurationsskript benutzen, sollten Sie ein Auge darauf werfen, welche Funktionen durch die automatische Erkennung aktiviert werden. Schalten Sie Funktionen, die Sie nicht möchten, ausdrücklich durch Verwendung von --without-xxx oder --disable-xxx in der Variable CONFIGURE_ARGS einzeln ab.

.if defined(WITH_FOO)
LIB_DEPENDS+=        foo.0:${PORTSDIR}/devel/foo
CONFIGURE_ARGS+=    --enable-foo
.endif

Stellen Sie sich vor im obigen Beispiel ist eine Bibliothek libfoo auf dem System installiert. Der Nutzer will nicht, dass diese Applikation libfoo benutzt, also hat er die Option auf "off" im make config-Dialog umgestellt. Aber das Konfigurationsskript der Applikation hat erkannt, dass die Bibliothek auf dem System vorhanden ist und fügt ihre Funktionen in die Binärdatei ein. Falls der Nutzer sich nun entschliesst libfoo von seinem System zu entfernen, dann wird das Ports-System nicht protestieren (es wurde keine Abhängigkeit von libfoo eingetragen), aber die Applikation bricht ab.

.if defined(WITH_FOO)
LIB_DEPENDS+=        foo.0:${PORTSDIR}/devel/foo
CONFIGURE_ARGS+=    --enable-foo
.else
CONFIGURE_ARGS+=    --disable-foo
.endif

Im zweiten Beispiel wird die Bibliothek libfoo explizit abgeschaltet. Das Konfigurationsskript aktiviert die entsprechenden Funktionen nicht in der Applikation trotz der Anwesenheit der Bibliothek auf dem System.

Diese Variable listet den Namen des Verzeichnisses, welches erstellt wird, wenn die Distfiles der Applikation extrahiert werden. Wenn unser vorheriges Beispiel in einem Verzeichnis namens foo (und nicht foo-1.0) extrahiert wurde, würden Sie schreiben:

WRKSRC=      ${WRKDIR}/foo

oder möglicherweise

WRKSRC=      ${WRKDIR}/${PORTNAME}
	  

Wenn der Port überhaupt nicht in einem Unterverzeichnis extrahiert wird, sollten Sie dies mit dem Setzen von NO_WRKSUBDIR anzeigen.

NO_WRKSUBDIR= yes

Falls Ihr Paket nicht mit anderen Paketen koexistieren kann (wegen Dateikonflikten, Laufzeit-Inkompatibilitäten usw.), führen Sie bitte die anderen Paketnamen in der Variable CONFLICTS_INSTALL auf. Sie können hier Shell-Globs wie * und ? verwenden. Paketnamen sollten in der gleichen Weise aufgezählt werden, wie sie in /var/db/pkg auftauchen. Bitte stellen Sie sicher, dass CONFLICTS nicht mit dem Paket des Ports selbst übereinstimmt, da ansonsten das Erzwingen der Installation durch FORCE_PKG_REGISTER nicht länger funktionieren wird.

Wenn Ihr Port nicht gebaut werden kann, wenn ein bestimmter Port bereits installiert ist, geben Sie diesen in der Variable CONFLICTS_BUILD an. Sie können hier Shell-Globs wie * und ? verwenden. Paketnamen sollten in der gleichen Weise aufgezählt werden, wie sie in /var/db/pkg auftauchen. Die CONFLICTS_BUILD-Prüfung erfolgt vor dem Bau des Ports. Baukonflikte werden im erzeugten Paket nicht verzeichnet.

Wenn Ihr Port nicht gebaut werden kann, wenn ein bestimmter Port bereits installiert ist und das aus dem Port erzeugte Paket nicht mit dem anderen Paket koexistieren kann, geben Sie das andere Paket in der Variable CONFLICTS an. Sie können hier Shell-Globs wie * und ? verwenden. Paketnamen sollten in der gleichen Weise aufgezählt werden, wie sie in /var/db/pkg auftauchen. Bitte stellen Sie sicher, dass CONFLICTS_INSTALL nicht mit dem Paket des Ports selbst übereinstimmt, da ansonsten das Erzwingen der Installation durch FORCE_PKG_REGISTER nicht länger funktionieren wird. Die CONFLICTS-Prüfung erfolgt vor dem Bau des Ports und vor der Installation des gebauten Ports.

Nutzen Sie die Makros in bsd.port.mk, um korrekte Modi und Eigentümer von Dateien in Ihren *-install-Targets sicherzustellen.

Das sind grundsätzlich alle install-Befehle mit ihren passenden Flags.

Zerlegen Sie keine Binärdateien manuell, wenn Sie es nicht müssen. Alle Binaries sollten gestripped werden; allerdings vermag das INSTALL_PROGRAM-Makro gleichzeitig eine Binärdatei zu installieren und zu strippen (beachten Sie den nächsten Abschnitt). Das Makro INSTALL_LIB erledigt das gleiche für Shared-Libraries.

Wenn Sie eine Datei strippen müssen, aber weder das INSTALL_PROGRAM- noch das INSTALL_LIB-Makro nutzen wollen, dann kann ${STRIP_CMD} Ihr Programm strippen. Dies wird typischerweise innerhalb des post-install-Targets gemacht. Zum Beispiel:

post-install:
    ${STRIP_CMD} ${PREFIX}/bin/xdl

Nutzen Sie file(1) für die installierte Applikation, um zu überprüfen, ob eine Binärdatei gestripped ist oder nicht. Wenn es nicht meldet not stripped, dann ist es bereits gestripped. Zudem wird strip(1) nicht ein bereits gestripptes Programm nochmals versuchen zu strippen, sondern wird stattdessen einfach sauber beenden.

Manchmal muss man eine große Zahl von Dateien unter Erhalt ihrer hierarchischen Struktur installieren, d.h. Kopieraktionen über einen ganzen Verzeichnisbaum von WRKSRC zu einem Zielverzeichnis unter PREFIX.

Für diesen Fall gibt es zwei Makros. Der Vorteil der Nutzung dieser Makros anstatt cp ist, dass sie korrekte Besitzer und Berechtigungen auf den Zieldateien garantieren. Das erste Makro, COPYTREE_BIN, wird alle installierten Dateien ausführbar markieren und damit passend für die Installation in PREFIX/bin vorbereiten. Das zweite Makro, COPYTREE_SHARE, setzt keine Ausführungsberechtigungen auf Dateien und ist daher geeignet für die Installation von Dateien im Target von PREFIX/share.

post-install:
    ${MKDIR} ${EXAMPLESDIR}
    (cd ${WRKSRC}/examples/ && ${COPYTREE_SHARE} \* ${EXAMPLESDIR})

Dieses Beispiel wird den Inhalt des examples-Verzeichnisses im Distfile des Drittanbieters in das Beispielverzeichnis Ihres Ports kopieren.

post-install:
    ${MKDIR} ${DATADIR}/summer
    (cd ${WRKSRC}/temperatures/ && ${COPYTREE_SHARE} "June July August" ${DATADIR}/summer/)

Und dieses Beispiel wird die Daten der Sommermonate in das summer-Unterverzeichnis eines DATADIR installieren.

Zusätzliche find-Argumente können mit dem dritten Argument an die COPYTREE_*-Makros übergeben werden. Um zum Beispiel alle Dateien aus dem 1. Beispiel ohne die Makefiles zu installieren, kann man folgenden Befehl benutzen.

post-install:
    ${MKDIR} ${EXAMPLESDIR}
    (cd ${WRKSRC}/examples/ && \
	${COPYTREE_SHARE} \* ${EXAMPLESDIR} "! -name Makefile")

Beachten Sie bitte, dass diese Makros die installierten Dateien nicht zur pkg-plist hinzufügen, Sie müssen sie immer noch selbst auflisten.

Falls Ihre Software zusätzlich zu den üblichen Manualpages und Info-Seiten weitere Dokumentation hat und Sie diese für nützlich halten, dann installieren Sie sie unter PREFIX/share/doc. Dies kann wie vorstehend im Target des post-install geschehen.

Legen Sie ein neues Verzeichnis für Ihren Port an. Das Verzeichnis sollte wiederspiegeln, was der Port ist. Das bedeutet normalerweise PORTNAME. Wie auch immer, wenn Sie meinen, der Nutzer möchte verschiedene Versionen des Ports zur gleichen Zeit installiert haben, dann können Sie die gesamte Variable PKGNAME nutzen.

Machen Sie die Installation von der Variablen NOPORTDOCS abhängig, damit die Nutzer sie in /etc/make.conf abschalten können:

post-install:
.if !defined(NOPORTDOCS)
    ${MKDIR} ${DOCSDIR}
    ${INSTALL_MAN} ${WRKSRC}/docs/xvdocs.ps ${DOCSDIR}
.endif

Hier einige praktische Variablen und wie sie standardmässig bei Verwendung im Makefile expandiert werden:

Die Variablen werden nach PLIST_SUB exportiert. Ihre Werte erscheinen dort als Pfadnamen relativ zu PREFIX, falls möglich. Das bedeutet, dass share/doc/PORTNAME standardmässig ersetzt wird durch %%DOCSDIR%% in der Packliste usw. (mehr zur Ersetzung durch die pkg-plist finden Sie hier).

Alle installierten Dokumentationsdateien und –Verzeichnisse sollten in der pkg-plist dem %%PORTDOCS%%-Präfix enthalten sein, zum Beispiel:

%%PORTDOCS%%%%DOCSDIR%%/AUTHORS
%%PORTDOCS%%%%DOCSDIR%%/CONTACT
%%PORTDOCS%%@dirrm %%DOCSDIR%%

Alternativ zur Auflistung der Dokumentationsdateien in der pkg-plist kann in einem Port auch die Variable PORTDOCS gesetzt werden für eine Liste von Dateien und Shell-Globs, um diese zur endgültigen Packliste hinzuzufügen. Die Namen werden relativ zur Variable DOCSDIR sein. Wenn Sie also einen Port haben, welcher PORTDOCS benutzt, und Sie haben eine vom Standard abweichenden Platz für seine Dokumentation, dann müssen Sie die Variable DOCSDIR entsprechend setzen. Wenn ein Verzeichnis in PORTDOCS aufgeführt ist, oder von einem Shell-Glob dieser Variable abgebildet wird, dann wird der komplette Verzeichnisbaum inklusive Dateien und Verzeichnissen in der endgültigen Packliste aufgenommen. Wenn die Variable NOPORTDOCS gesetzt ist, dann werden die Dateien und Verzeichnisse, die in PORTDOCS aufgelistet sind, nicht installiert und werden auch nicht zur Packliste des Ports hinzugefügt. Wie oben gezeigt bleibt es dem Port selbst überlassen, die Dokumentation in PORTDOCS zu installieren. Ein typisches Beispiel für den Gebrauch von PORTDOCS sieht wie folgt aus:

PORTDOCS=       README.* ChangeLog docs/*

Lassen Sie den Port die Dateien in die richtigen Unterverzeichnisse von PREFIX verteilen. Einige Ports werfen alles in einen Topf und legen es im Unterverzeichnis mit dem Namen des Ports ab, was falsch ist. Ausserdem legen viele Ports alles ausser Binaries, Header-Dateien und Manualpages in ein Unterverzeichnis von lib, was natürlich auch nicht der BSD-Philosophie entspricht und nicht gut funktioniert. Viele der Dateien sollten in eines der folgenden Verzeichnisse geschoben werden: etc (Konfigurationsdateien), libexec (intern gestartete Binärdateien), sbin (Binärdateien für Superuser/Manager), info (Dokumentation für Info-Browser) oder share (Architektur-unabhängige Dateien). Lesen Sie hierzu hier(7); weitestgehend greifen die Regeln für /usr auch für /usr/local. Die Ausnahme sind Ports, welche mit „news“ aus dem USENET arbeiten. In diesem Falle sollte PREFIX/news als Zielort für die Dateien benutzt werden.

Diese Variable zeigt an, dass wir keine binären Pakete dieser Applikation erzeugen dürfen - z.B. wenn die Lizenz die Weiterverteilung von binären Paketen oder Paketen verbietet, die aus verändertem Quelltext erzeugt wurden.

Die DISTFILES des Ports dürfen allerdings frei über FTP/HTTP Mirrors weiterverbreitet werden. Sie dürfen auch auf CD-ROM (oder ähnlichen Medien) weiterverbreitet werden - es sei denn, NO_CDROM ist ebenfalls gesetzt.

NO_PACKAGE sollte auch benutzt werden, wenn das binäre Paket nicht allgemein brauchbar ist und die Applikation immer aus dem Quelltext kompiliert werden sollte. Zum Beispiel, wenn die Applikation konfigurierte Informationen über den Rechner/Installationsort bei der Installation einkompiliert bekommt, setzen Sie NO_PACKAGE.

NO_PACKAGE sollte auf eine Zeichenkette gesetzt werden, die den Grund beschreibt, warum kein Paket erzeugt werden soll.

Diese Variable gibt an, dassobwohl wir binäre Pakete erzeugen dürfen – wir weder diese Pakete noch die DISTFILES des Ports auf einer CD-ROM (oder ähnlichen Medien) verkaufen dürfen. Die DISTFILES des Ports dürfen allerdings immer noch auf FTP/HTTP Mirrors.

Wenn diese Variable und auch NO_PACKAGE gesetzt ist, dann werden nur die DISTFILES des Ports erhältlich sein – und das nur mittels FTP/HTTP.

NO_CDROM sollte auf eine Zeichenkette gesetzt werden, die den Grund beschreibt, warum der Port nicht auf CD-ROM weiterverbreitet werden kann. Das sollte z.B. gemacht werden, wenn die Lizenz des Ports nur für „nichtkommerzielle Zwecke“ gilt.

Dateien, die in der Variable NOFETCHFILES aufgelistet sind, sind von keiner der MASTER_SITES abrufbar. Ein Beispiel solch einer Datei ist eine selbige, welche vom Anbieter auf CD-ROM bereitgestellt wird.

Werkzeuge, die das Vorhandensein dieser Dateien auf den MASTER_SITES überprüfen, sollten diese Dateien ignorieren und sie nicht melden.

Setzen Sie diese Variable, wenn die Lizenz der Applikation weder das Spiegeln der DISTFILES der Applikation noch das Weiterverbreiten von binären Paketen in jedweder Art erlaubt.

NO_CDROM oder NO_PACKAGE sollten nicht zusammen mit RESTRICTED gesetzt werden, weil letztere Variable die anderen beiden impliziert.

RESTRICTED sollte auf eine Zeichenkette gesetzt werden, die den Grund beschreibt, warum der Port nicht weiterverbreitet werden kann. Typischerweise besagt dies, dass der Port proprietäre Software enthält und der Benutzer die DISTFILES manuell herunterladen muss – möglicherweise erst nachdem er sich für die Software registriert oder die Bedingungen eines Endbenutzer-Lizenzvertrags (EULA) akzeptiert hat.

Wenn RESTRICTED oder NO_CDROM gesetzt ist, ist diese Variable auf ${DISTFILES} ${PATCHFILES} voreingestellt, sonst ist sie leer. Wenn nicht jede dieser Dateien beschränkt ist, dann führen Sie die betroffenen Dateien in dieser Variable auf.

Beachten Sie, dass der Porter für jede aufgeführte Distributionsdatei einen Eintrag zu /usr/ports/LEGAL hinzufügen sollte, der genau beschreibt, was die Beschränkung mit sich bringt.

Das Ports-Framework von FreeBSD unterstützt das parallele Bauen von Ports, indem es mehrere make-Instanzen ausführt, damit SMP-Systeme ihre gesamte CPU-Rechenleistung ausnützen können und so das Bauen von Ports schneller und effektiver werden kann.

Dies ermöglicht der Parameter -jX an make(1), wenn Code von Drittanbietern kompiliert wird. Leider können nicht alle Ports wirklich gut mit dem Parallelbau umgehen. Deshalb ist es erforderlich, dass dieses Feature explizit durch MAKE_JOBS_SAFE=yes irgendwo unterhalb des Abschnitts für Abhängigkeiten im Makefile aktiviert wird.

Eine weitere Möglichkeit im Umgang mit dieser Option besteht für den Maintainer darin, MAKE_JOBS_UNSAFE=yes zu setzen. Diese Variable wird dann verwendet, wenn ein Port bekannterweise mit -jX nicht gebaut werden kann, der Benutzer jedoch für alle Ports den Mehrprozessorbau durch FORCE_MAKE_JOBS=yes in /etc/make.conf erzwingt.

Wenn Ihr Port GNU make benutzt, dann setzen Sie bitte USE_GMAKE=yes.

Wenn Ihr Port eine X-Applikation ist, die Makefile-Dateien aus Imakefile-Dateien mit imake erzeugt, dann setzen Sie USE_IMAKE=yes. Das sorgt dafür, dass die Konfigurationsphase automatisch ein xmkmf -a ausführt. Wenn das Flag -a ein Problem für Ihren Port darstellt, setzen Sie XMKMF=xmkmf. Wenn der Port imake benutzt, aber das install.man-Target nicht versteht, dann sollte NO_INSTALL_MANPAGES=yes gesetzt werden.

Wenn das Makefile im Quelltext Ihres Ports etwas anderes als all als Haupt-Build-Target hat, setzen Sie ALL_TARGET entsprechend. Das Gleiche gilt für install und INSTALL_TARGET.

Wenn Ihr Port ein configure-Skript benutzt, um Makefile-Dateien aus Makefile.in-Dateien zu erzeugen, setzen Sie GNU_CONFIGURE=yes. Wenn Sie dem configure-Skript zusätzliche Argumente übergeben wollen (das Vorgabeargument ist --prefix=${PREFIX} --infodir=${PREFIX}/${INFO_PATH} --mandir=${MANPREFIX}/man --build=${CONFIGURE_TARGET}), setzen Sie diese zusätzlichen Argumente in CONFIGURE_ARGS. Zusätzliche Umgebungsvariablen können überdie Variable CONFIGURE_ENV übergeben werden.

Wenn Ihr Port SCons benutzt, definieren Sie USE_SCONS=yes.

Um SConstruct im Quelltext alles, was SCons in SCONS_ENV übergeben wird, respektieren zu lassen (das ist hauptsächlich CC/CXX/CFLAGS/CXXFLAGS), patchen Sie SConstruct, sodass das Build Environment wie folgt konstruiert wird:

env = Environment(**ARGUMENTS)

Es kann dann mit env.Append und env.Replace modifiziert werden.

Die verschiedenen GNU autotools stellen einen Abstraktionsmechanismus bereit für das Kompilieren von Software für eine Vielfalt von Betriebssystemen und Maschinenarchitekturen. Innerhalb der Ports-Sammlung kann ein einzelner Port diese Werkzeuge mit Hilfe eines einfachen Konstrukts benutzen:

USE_AUTOTOOLS= tool:version[:operation] ...

Als dies geschrieben wurde konnte tool eins von libtool, libltdl, autoconf, autoheader, automake oder aclocal sein.

version gibt die einzelne Werkzeug-Revision an, die benutzt werden soll (siehe devel/{automake,autoconf,libtool}[0-9]+ für mögliche Versionen).

operation ist eine optionale Angabe, die modifiziert, wie das Werkzeug benutzt wird.

Es können auch mehrere Werkzeuge angegeben werden – entweder durch Angabe aller in einer einzigen Zeile oder durch Benutzung des += Makefile-Konstrukts.

Schliesslich gibt es das spezielle Tool, genannt autotools, das der Einfachheit dient indem es von alle verfügbaren Versionen der Autotools abhängt, was sinnvoll für Cross-Development ist. Dies kann auch erreicht werden, indem man den Port devel/autotools installiert.

Shared-Libraries, die das GNU Build-System benutzen, verwenden normalerweise libtool, um die Kompilierung und Installation solcher Bibliotheken anzupassen. Die übliche Praxis ist, eine Kopie von libtool, die mit dem Quelltext geliefert wird, zu benutzen. Falls Sie ein externes libtool benötigen, können Sie die Version, die von der Ports-Sammlung bereitgestellt wird, benutzen:

USE_AUTOTOOLS= libtool:version[:env]

Ohne zusätzliche Angaben sagt libtool:version dem Build-System, dass es das Konfigurationsskript mit der auf dem System installierten Kopie von libtool patchen soll. Die Variable GNU_CONFIGURE ist impliziert. Außerdem werden einige make– und shell-Variablen zur weiteren Benutzung durch den Port gesetzt. Für Genaueres siehe bsd.autotools.mk.

Mit der Angabe :env wird nur die Umgebung vorbereitet.

Schließlich können optional LIBTOOLFLAGS und LIBTOOLFILES gesetzt werden, um die häufigsten Argumente und durch libtool gepatchten Dateien außer Kraft zu setzen. Die meisten Ports werden das aber nicht brauchen. Für Weiteres siehe bsd.autotools.mk.

Einige Ports benutzen das libltdl-Bibliothekspaket, welches Teil der libtool-Suite ist. Der Gebrauch dieser Bibliothek macht nicht automatisch den Gebrauch von libtool selbst nötig, deshalb wird ein separates Konstrukt zur Verfügung gestellt.

USE_AUTOTOOLS= libltdl:version

Im Moment sorgt dies nur für eine LIB_DEPENDS-Abhängigkeit von dem entsprechenden libltdl-Port und wird zur Vereinfachung zur Verfügung gestellt, um Abhängigkeiten von den Autotools-Ports ausserhalb des USE_AUTOTOOLS-Systems zu eliminieren. Es gibt keine weiteren Angaben für dieses Werkzeug.

Manche Ports enthalten kein Konfigurationsskript, sondern eine autoconf-Vorlage in der configure.ac-Datei. Sie können die folgenden Zuweisungen benutzen, um autoconf das Konfigurationsskript erzeugen zu lassen, und auch autoheader Header-Vorlagen zur Benutzung durch das Konfigurationsskript erzeugen zu lassen.

USE_AUTOTOOLS=    autoconf:version[:env]

und

USE_AUTOTOOLS=    autoheader:version

welches auch die Benutzung von autoconf:version impliziert.

Ähnlich wie bei libtool, bereitet die Angabe des optionalen :env nur die Umgebung für weitere Benutzung vor. Ohne dieses wird der Port auch gepatched und erneut konfiguriert.

Die zusätzlichen optionalen Variablen AUTOCONF_ARGS und AUTOHEADER_ARGS können durch das Makefile des Ports ausser Kraft gesetzt werden, wenn erforderlich. Wie bei den libtool-Äquivalenten werden die meisten Ports dies aber nicht benötigen.

Manche Pakete enthalten nur Makefile.am-Dateien. Diese müssen durch automake in Makefile.in-Dateien konvertiert und dann durch configure weiterbearbeitet werden, um schließlich ein Makefile zu erzeugen.

Ähnliches gilt für Pakete, die gelegentlich keine aclocal.m4-Dateien mitliefern, welche ebenfalls zum Erstellen der Software benötigt werden. Diese können durch aclocal erzeugt werden, welches configure.ac oder configure.in durchsucht.

aclocal hat eine ähnliche Beziehung zu automake wie autoheader zu autoconf – beschrieben im vorherigen Abschnitt. aclocal impliziert die Benutzung von automake, also haben wir:

USE_AUTOTOOLS=    automake:version[:env]

und

USE_AUTOTOOLS=    aclocal:version

was auch die Benutzung von automake:version impliziert.

Ähnlich wie bei libtool und autoconf, bereitet die optionale Angabe :env nur die Umgebung zur weiteren Benutzung vor. Ohne sie wird der Port erneut konfiguriert.

Wie schon autoconf und autoheader, hat sowohl automake als auch aclocal eine optionale Argument-Variable AUTOMAKE_ARGS bzw. ACLOCAL_ARGS, die durch das Makefile des Ports, falls nötig, außer Kraft gesetzt werden kann.

Wenn Ihr Port gettext benötigt, setzen Sie einfach USE_GETTEXT auf yes, und Ihr Port bekommt die Abhängigkeit von devel/gettext. Der Wert von USE_GETTEXT kann auch die benötigte Version der libintl-Bibliothek angeben, der grundlegenden Teil von gettext – jedoch wird von der Benutzung dieser Funktion dringend abgeraten: Ihr Port sollte einfach nur mit der aktuellen Version von devel/gettext funktionieren.

Ein ziemlich häufiger Fall ist, dass ein Port gettext und configure benutzt. Normalerweise sollte GNU configure gettext automatisch finden können. Sollte das einmal nicht funktionieren, können Hinweise über den Ort von gettext in CPPFLAGS und LDFLAGS wie folgt übergeben werden:

USE_GETTEXT=    yes
CPPFLAGS+=      -I${LOCALBASE}/include
LDFLAGS+=       -L${LOCALBASE}/lib

GNU_CONFIGURE=  yes
CONFIGURE_ENV=  CPPFLAGS="${CPPFLAGS}" \
	        LDFLAGS="${LDFLAGS}"

Natürlich kann der Code kompakter sein, wenn es keine weiteren Flags gibt, die configure übergeben werden müssen:

USE_GETTEXT=    yes
GNU_CONFIGURE=  yes
CONFIGURE_ENV=  CPPFLAGS="-I${LOCALBASE}/include" \
	        LDFLAGS="-L${LOCALBASE}/lib"

Manche Softwareprodukte erlauben die Deaktivierung von NLS - z.B. durch Übergeben von --disable-nls an configure. In diesem Fall sollte Ihr Port gettext abhängig vom Status von WITHOUT_NLS benutzen. Für Ports mit niedriger bis mittlerer Komplexität können Sie sich auf das folgende Idiom verlassen:

GNU_CONFIGURE=          yes

.if !defined(WITHOUT_NLS)
USE_GETTEXT=            yes
PLIST_SUB+=             NLS=""
.else
CONFIGURE_ARGS+=        --disable-nls
PLIST_SUB+=             NLS="@comment "
.endif

Der nächste Punkt auf Ihrer Todo-Liste ist dafür zu sorgen, dass die Message-Catalog-Dateien nur bedingt in der Packliste aufgeführt werden. Der Makefile-Teil dieser Aufgabe ist schon durch obiges Idiom erledigt. Das wird im Abschnitt über Fortgeschrittene pkg-plist-Methoden erklärt. Kurz gesagt, jedes Vorkommen von %%NLS%% in pkg-plist wird durch „@comment “, wenn NLS abgeschaltet ist, oder durch eine leere Zeichenkette, wenn NLS aktiviert ist, ersetzt. Folglich werden die Zeilen, denen %%NLS%% vorangestellt ist, zu reinen Kommentaren in der endgültigen Packliste, wenn NLS abgeschaltet ist; andernfalls wird der Prefix einfach nur ausgelassen. Alles, was Sie jetzt noch machen müssen, ist %%NLS%% vor jedem Pfad zu einer Message-Catalog-Datei in pkg-plist einzufügen. Zum Beispiel:

%%NLS%%share/locale/fr/LC_MESSAGES/foobar.mo
%%NLS%%share/locale/no/LC_MESSAGES/foobar.mo

In sehr komplexen Fällen müssen Sie eventuell fortgeschrittenere Techniken als die hier vorgestellte benutzen - wie z.B. Dynamische Packlistenerzeugung.

Bei der Installation von Message-Catalog-Dateien gibt es einen Punkt zu beachten. Ihr Zielverzeichnis, das unter LOCALBASE/share/locale liegt, sollte nur selten von Ihrem Port erzeugt und gelöscht werden. Die Verzeichnisse für die gebräuchlichsten Sprachen sind in /etc/mtree/BSD.local.dist aufgelistet; das heisst, sie sind Teil des Systems. Die Verzeichnisse für viele andere Sprachen sind Teil des Ports devel/gettext. Sie wollen vielleicht dessen pkg-plist zur Hand nehmen, um festzustellen, ob Ihr Port eine Message-Catalog-Datei für eine seltene Sprache installiert.

Die X11-Implementierung, welche die Ports-Sammlung bereitstellt, ist X.Org. Wenn Ihre Applikation von X-Komponenten abhängt, listen Sie die benötigten Komponenten in USE_XORG auf. Als dies geschrieben wurde, wurden die folgenden Komponenten bereitgestellt:

bigreqsproto compositeproto damageproto dmx dmxproto evieproto fixesproto fontcacheproto fontenc fontsproto fontutil glproto ice inputproto kbproto libfs oldx printproto randrproto recordproto renderproto resourceproto scrnsaverproto sm trapproto videoproto x11 xau xaw xaw6 xaw7 xaw8 xbitmaps xcmiscproto xcomposite xcursor xdamage xdmcp xevie xext xextproto xf86bigfontproto xf86dgaproto xf86driproto xf86miscproto xf86rushproto xf86vidmodeproto xfixes xfont xfontcache xft xi xinerama xineramaproto xkbfile xkbui xmu xmuu xorg-server xp xpm xprintapputil xprintutil xpr oto xproxymngproto xrandr xrender xres xscrnsaver xt xtrans xtrap xtst xv xvmc xxf86dga xxf86misc xxf86vm.

Die aktuelle Liste finden Sie immer in /usr/ports/Mk/bsd.xorg.mk.

Das Mesa Projekt ist ein Versuch, eine freie OpenGL Implementierung bereitzustellen. Sie können eine Abhängigkeit von verschiedenen Komponenten diese Projektes in der Variable USE_GL spezifizieren. ouml;gliche Optionen sind: glut, glu, glw, glew, gl und linux. Für Abwärtskompatibilität gilt der Wert yes als glu.

USE_XORG=   xrender xft xkbfile xt xaw
USE_GL=     glu

Viele Ports definieren USE_XLIB, was dafür sorgt, dass der Port von allen (rund 50) Bibliotheken abhängt. Diese Variable existiert, um Abwärtskompatibilität sicherzustellen (sie stammt noch aus der Zeit vor dem modularem X.Org), und sollte bei neuen Ports nicht mehr benutzt werden.

# Port benutzt X11-Bibliotheken und hängt vom Font-Server sowie
# von kyrillischen Schriftarten ab.
RUN_DEPENDS=   ${LOCALBASE}/bin/xfs:${X_FONTSERVER_PORT} \
               ${LOCALBASE}/lib/X11/fonts/cyrillic/crox1c.pcf.gz:${X_FONTS_CYRILLIC_PORT}

USE_XORG=      x11 xpm

Wenn Ihr Port eine Motif-Bibliothek benötigt, definieren Sie USE_MOTIF im Makefile. Die Standard-Motif-Implementierung ist x11-toolkits/open-motif. Benutzer können stattdessen x11-toolkits/lesstif wählen, indem Sie die WANT_LESSTIF-Variable setzen.

Die Variable MOTIFLIB wird von bsd.port.mk auf die entsprechende Motif-Bibliothek gesetzt. Bitte patchen Sie den Quelltext Ihres Ports, sodass er überall ${MOTIFLIB} benutzt, wo die Motif-Bibliothek im Original Makefile oder Imakefile referenziert wird.

Es gibt zwei verbreitete Fälle:

Anmerkung: MOTIFLIB expandiert (normalerweise) zu -L/usr/X11R6/lib -lXm oder /usr/X11R6/lib/libXm.a - d.h. Sie müssen kein -L oder -l davor einfügen.

Wenn Ihr Port Schriftarten für das X-Window-System installiert, legen Sie diese nach LOCALBASE/lib/X11/fonts/local.

Manche Applikationen benötigen ein funktionierendes X11-Display, damit die Kompilierung funktioniert. Das stellt für Systeme, die ohne Display laufen, ein Problem dar. Wenn die folgende Variable benutzt wird, startet die Bauumgebung den virtuellen Framebuffer-X-Server, und ein funktionierendes DISPLAY wird dem Build übergeben.

USE_DISPLAY=  yes

Desktop-Einträge (Freedesktop Standard) können in Ihrem Port einfach über die DESKTOP_ENTRIES-Variable erzeugt werden. Diese Einträge erscheinen dann im Applikationsmenü von standardkonformen Desktop-Umgebungen wie GNOME oder KDE. Die .desktop-Datei wird dann automatisch erzeugt, installiert und der pkg-plist hinzugefügt. Die Syntax ist:

DESKTOP_ENTRIES=  "NAME" "COMMENT" "ICON" "COMMAND" "CATEGORY" StartupNotify

Die Liste der möglichen Kategorien ist auf der Freedesktop Webseite abrufbar. StartupNotify zeigt an, ob die Applikation den Status in Umgebungen, die Startup-Notifications kennen, löschen wird.

Beispiel:

DESKTOP_ENTRIES=  "ToME" "Roguelike game based on JRR Tolkien's work" \
	          "${DATADIR}/xtra/graf/tome-128.png" \
	          "tome -v -g" "Application;Game;RolePlaying;" \
	          false

Wenn USE_QT_VER gesetzt ist, werden dem configure-Skript einige nützliche Einstellungen übergeben:

CONFIGURE_ARGS+= --with-qt-includes=${QT_PREFIX}/include \
	         --with-qt-libraries=${QT_PREFIX}/lib \
	         --with-extra-libs=${LOCALBASE}/lib \
	         --with-extra-includes=${LOCALBASE}/include
CONFIGURE_ENV+=  MOC="${MOC}" CPPFLAGS="${CPPFLAGS} ${QTCPPFLAGS}" LIBS="${QTCFGLIBS}" \
	         QTDIR="${QT_PREFIX}" KDEDIR="${KDE_PREFIX}"

Wenn USE_QT_VER auf 4 gesetzt ist, werden auch die folgenden Einstellungen übergeben:

CONFIGURE_ENV+= UIC="${UIC}" QMAKE="${QMAKE}" QMAKESPEC="${QMAKESPEC}"
MAKE_ENV+=      QMAKESPEC="${QMAKESPEC}"

Wenn USE_QT_VER auf 4 gesetzt ist, können individuelle Qt4-Tool- und Bibliotheksabhängigkeiten in der Variable QT_COMPONENTS angegeben werden. An jede Komponente kann _build oder _run als Suffix angehängt werden, was eine Abhängigkeit zur Build- bzw. Laufzeit angibt. Ohne Suffix gilt die Abhängigkeit sowohl zur Build- als auch zur Laufzeit. Bibliothekskomponenten sollten normalerweise ohne Suffix angegeben werden, Tool-Komponenten mit _build und Plugin-Komponenten mit _run. Die gebräuchlichsten Komponenten werden im Folgenden angegeben (alle verfügbaren Komponenten sind in _QT_COMPONENTS_ALL in /usr/ports/Mk/bsd.qt.mk aufgelistet):

Sie können herausfinden, welche Bibliotheken die Applikation benötigt, indem Sie nach erfolgreicher Kompilierung ldd auf die Hauptbinärdatei anwenden.

USE_QT_VER=    4
QT_COMPONENTS= gui moc_build qmake_build rcc_build uic_build

Wenn die Applikation keine configure Datei, sondern eine .pro Datei hat, können Sie das Folgende benutzen:

HAS_CONFIGURE=    yes

do-configure:
	@cd ${WRKSRC} && ${SETENV} ${CONFIGURE_ENV} \
	        ${QMAKE} -unix PREFIX=${PREFIX} texmaker.pro

Beachten Sie die Ähnlichkeit mit der qmake-Zeile im mitgelieferten BUILD.sh-Skript. Die Übergabe von CONFIGURE_ENV stellt sicher, dass qmake die QMAKESPEC-Variable übergeben bekommt, ohne die es nicht funktioniert. qmake erzeugt Standard-Makefiles, sodass es nicht nötig ist ein eigenes neues build-Target zu schreiben.

Qt-Applikationen sind oft so geschrieben, dass sie plattformübergreifend sind, und oft ist X11/Unix nicht die Plattform, auf der sie entwickelt werden. Das sorgt oft für bestimmte fehlende Kleinigkeiten wie z.B.:

Falls Ihre Anwendung von KDE 4 abhängt, weisen Sie USE_KDE4 eine Liste mit benötigten Komponenten zu. Die am häufigsten gebrauchten sind unten aufgelistet (_USE_KDE4_ALL in /usr/ports/Mk/bsd.kde4.mk enthält stets die aktuelle Liste):

KDE 4-Ports werden unter ${KDE4_PREFIX}, zur Zeit /usr/local/kde4, installiert, um Konflikte mit KDE 3-Ports zu verhindern. Dies wird durch Auflisten der Komponente kdeprefix erreicht, welche die standardmäßig gesetzte Variable PREFIX überschreibt. Die Ports übernehmen jedoch, jeden über die Umgebungsvariable MAKEFLAGS oder make-Parameter festgelegten Wert für PREFIX.

Es könnte bei der Installation von KDE 4-Ports zu Konflikten mit KDE 3-Ports kommen, sodass diese bei aktivierter kdeprefix-Komponente unter ${KDE4_PREFIX} installiert werden. Der Standardwert von KDE4_PREFIX ist zur Zeit /usr/local/kde4. Es ist auch möglich, KDE 4-Ports unter einem angepassten PREFIX zu installieren. Wenn PREFIX als MAKEFLAGS-Umgebungsvariable oder als make-Parameter gesetzt wird, überschreibt dies den von kdeprefix festgelegten Wert.

USE_CMAKE=     yes
USE_KDE4=      automoc4 kdelibs kdeprefix
USE_QT_VER=    4
QT_COMPONENTS= qmake_build moc_build rcc_build uic_build

Wenn Ihr Port ein Java™ Development Kit (JDK™) benötigt, entweder zum Bauen, zur Laufzeit oder sogar, um das Distfile auszupacken, dann sollten Sie USE_JAVA setzen.

Es gibt mehrere JDKs in der Ports-Sammlung– von verschiedenen Anbietern und in verschiedenen Versionen. Wenn Ihr Port eine bestimmte dieser Versionen benötigt, können Sie definieren welche. Die aktuelle Version ist java/jdk16.

Das Folgende ist eine Liste aller Variablen, die ein Port bekommt, nachdem er USE_JAVA gesetzt hat:

Sie können das java-debug make-Target benutzen, um Information zum Debuggen Ihres Ports zu erhalten. Es wird die Werte vieler der obenangegebenen Variablen anzeigen.

Zusätzlich sind die folgenden Konstanten definiert, damit alle Java-Ports auf eine konsistente Art installiert werden können:

Die entsprechenden Einträge sind sowohl in PLIST_SUB (dokumentiert in Abschnitt 7.1, „Änderungen an pkg-plist mit Hilfe von make-Variablen“) als auch in SUB_LIST definiert.

Wenn der Port mit Apache Ant kompiliert werden soll, muss er USE_ANT setzen. Ant wird dann als das sub-make-Kommando betrachtet. Wenn kein do-build-Target vom Port definiert ist, wird eine Standardvorgabe benutzt, die einfach Ant entsprechend MAKE_ENV, MAKE_ARGS und ALL_TARGET aufruft. Das ähnelt dem USE_GMAKE-Mechanismus, der in Abschnitt 6.3, „Build-Mechanismen“ dokumentiert ist.

Wenn Sie eine Java-Bibliothek portieren, sollte Ihr Port die JAR-Datei(en) in ${JAVAJARDIR} installieren, und alles andere unter ${JAVASHAREDIR}/${PORTNAME} (ausgenommen die Dokumentation - siehe unten). Um die Größe der Packlistendatei zu reduzieren, können die JAR-Datei(en) direkt im Makefile angegeben werden. Benutzen Sie einfach die folgende Anweisung (wobei myport.jar der Name der JAR-Datei ist, die als Teil des Ports installiert wird):

PLIST_FILES+= %%JAVAJARDIR%%/myport.jar

Beim Portieren einer Java-Applikation installiert der Port normalerweise alles unter einem einzigen Verzeichnis (inklusive seiner JAR-Abhängigkeiten). Die Benutzung von ${JAVASHAREDIR}/${PORTNAME} wird in dieser Beziehung dringend empfohlen. Es liegt im Entscheidungsbereich des Portierenden, ob der Port die zusätzlichen JAR-Abhängigkeiten unter diesem Verzeichnis installieren oder direkt die schon installierten (aus ${JAVAJARDIR}) benutzen soll.

Unabhängig von der Art Ihres Ports (Bibliothek oder Applikation), sollte die zusätzliche Dokumentation an die gleiche Stelle installiert werden wie bei jedem anderen Port auch. Das JavaDoc-Werkzeug ist dafür bekannt einen unterschiedlichen Satz von Dateien abhängig von der Version des benutzten JDKs zu erstellen. Für Ports, die nicht die Benutzung eines bestimmten JDKs vorgeben, ist es deshalb eine komplexe Aufgabe die Packliste (pkg-plist) festzulegen. Dies ist ein Grund, warum dringend angeraten wird, das PORTDOCS-Makro zu benutzen. Außerdem, selbst wenn Sie den Satz von Dateien, den javadoc erzeugen wird, voraussagen können, die Größe der resultierenden pkg-plist befürwortet die Benutzung von PORTDOCS.

Der Vorgabewert für DATADIR ist ${PREFIX}/share/${PORTNAME}. Es ist eine gute Idee, DATADIR für Java-Ports stattdessen auf ${JAVASHAREDIR}/${PORTNAME} zu setzen. In der Tat wird DATADIR automatisch zu PLIST_SUB (dokumentiert in Abschnitt 7.1, „Änderungen an pkg-plist mit Hilfe von make-Variablen“) hinzugefügt, d.h. Sie können %%DATADIR%% direkt in pkg-plist benutzen.

Zu der Frage, ob Java-Ports aus dem Quelltext gebaut werden, oder direkt bereitgestellte binäre Distributionen benutzt werden sollten, gab es, als dies geschrieben wurde, keine definierte Richtlinie. Allerdings ermutigen Mitglieder des FreeBSD Java-Projekts Porter dazu, Ihre Ports aus dem Quelltext kompilieren zu lassen, wann immer dies kein Problem darstellt.

Alle Eigenschaften, die in diesem Abschnitt präsentiert wurden sind in bsd.java.mk implementiert. Sollten Sie jemals der Meinung sein, dass Ihr Port ausgefeiltere Java-Unterstützung benötigt, schauen Sie bitte erst in das bsd.java.mk CVS Log, weil es normalerweise immer etwas Zeit braucht bis die neuesten Eigenschaften dokumentiert sind. Wenn Sie glauben, dass der fehlende Support auch für viele andere Java Ports nützlich sein könnte, wenden Sie sich bitte an die FreeBSD Java Language.

Obwohl es eine java-Kategorie für Fehlerberichte gibt, bezieht sich diese auf die JDK-Portierungsbemühungen des FreeBSD Java-Projektes. Deshalb sollten Sie Ihren Java-Port in der ports-Kategorie einreichen wie bei jeden anderen Port auch - es sei denn, die Angelegenheit, die Sie zu klären versuchen, steht in Zusammenhang entweder mit einer JDK-Implementierung oder bsd.java.mk.

Gleichermaßen gibt es eine definierte Richtlinie für die CATEGORIES eines Java-Ports, die in Abschnitt 5.3, „Kategorisierung“ erklärt wird.

Webanwendungen sollten nach PREFIX/www/programmname installiert werden. Der Einfachheit halber ist dieser Pfad sowohl im Makefile als auch in pkg-plist als WWWDIR verfügbar. Der relative Pfad PREFIX ist hingegen im Makefile durch die Variable WWWDIR_REL festgelegt.

Der Benutzername und die Benutzergruppe, mit deren Rechte Webanwendungen laufen, sind in WWWOWN und WWWGRP festgelegt. Standardwert ist bei beiden www. Falls ein Port mit anderen Rechten gestartet werden soll, so sollte die Anweisung WWWOWN?= myuser verwendet werden. Dies vereinfacht dem Benutzer eine Anpassung dieser Werte.

Falls die Webanwendung nicht explizit Apache benötigt, so sollte dieser auch nicht als Abhängigkeit des Ports aufgeführt werden. Dadurch bleibt es dem Benutzer überlassen Apache oder einen anderen Webserver zu verwenden.

Das Portieren von PEAR-Modulen ist sehr einfach.

Mit Hilfe der Variablen FILES, TESTS, DATA, SQLS, SCRIPTFILES, DOCS und EXAMPLES können die zu installierenden Dateien angegeben werden. Alle aufgeführten Dateien werden automatisch in die jeweiligen Verzeichnisse installiert und der Datei pkg-plist hinzugefügt.

Die Datei ${PORTSDIR}/devel/pear/bsd.pear.mk muss am Ende des Makefiles eingebunden werden.

PORTNAME=       Date
PORTVERSION=    1.4.3
CATEGORIES=     devel www pear

MAINTAINER=     example@domain.com
COMMENT=        PEAR Date and Time Zone Classes

BUILD_DEPENDS=  ${PEARDIR}/PEAR.php:${PORTSDIR}/devel/pear-PEAR
RUN_DEPENDS=    ${BUILD_DEPENDS}

FILES=          Date.php Date/Calc.php Date/Human.php Date/Span.php     \
	        Date/TimeZone.php
TESTS=          test_calc.php test_date_methods_span.php testunit.php   \
	        testunit_date.php testunit_date_span.php wknotest.txt   \
	        bug674.php bug727_1.php bug727_2.php bug727_3.php       \
	        bug727_4.php bug967.php weeksinmonth_4_monday.txt       \
	        weeksinmonth_4_sunday.txt weeksinmonth_rdm_monday.txt   \
	        weeksinmonth_rdm_sunday.txt
DOCS=           TODO
_DOCSDIR=       .

.include <bsd.port.pre.mk>
.include "${PORTSDIR}/devel/pear/bsd.pear.mk"
.include <bsd.port.post.mk>

Es gibt viele Probleme bei der gleichzeitigen Verwendung unterschiedlicher Versionen von wxWidgets-Bibliotheken (Dateien unterschiedlicher wxWidgets-Versionen haben denselben Dateinamen). In den Ports wurde das Problem dadurch gelöst, dass jede Version unter einem eigenen Namen installiert wird, der die Versionsnummer als Suffix beinhaltet.

Der offensichtliche Nachteil dabei ist, dass jede Anwendung so verändert werden muss, dass sie die erwartete Version vorfindet. Die meisten solcher Anwendungen benutzen das wx-config-Skript, um die benötigten Compiler- und Linkerflags zu erhalten. Dieses Skript hat für jede verfügbare Version einen anderen Namen. Die meisten Anwendungen beachten eine Umgebungsvariable oder ein Argument beim configure-Skript, um das gewünschte wx-config-Skript festzulegen. Ansonsten müssen sie gepatcht werden.

Um festzulegen, welche Version der wxWidgets verwendet werden soll, gibt es zwei Variablen (falls nur eine der beiden definiert wird, so wird die andere auf einen Standardwert gesetzt):

Es folgt eine Liste an möglichen wxWidgets-Versionen und deren zugehöriger Port:

Die Variablen in Tabelle 6.24, „Variablen, um die wxWidgets-Version festzulegen“ können auf einen oder mehrere (durch Leerzeichen getrennt) der folgenden Werte gesetzt werden:

Desweiteren gibt es Variablen, über die eine bevorzugte Version festgelegt werden kann. Die Versionen können als Liste angegeben werden, wobei die Reihenfolge der Priorisierung entspricht.

Desweiteren gibt es Anwendungen, die nicht direkt wxWidgets-Bibliotheken sind, aber trotzdem mit diesen zusammenhängen. Diese Anwendungen können über die Variable WX_COMPS festgelegt werden. Die folgenden Komponenten sind verfügbar:

Der Typ der Abhängigkeit kann für jede Komponente durch hinzufügen eines Suffix (durch Strichpunkt getrennt) festgelegt werden. Falls der Typ nicht angegeben wird, wird ein Standardwert verwendet (siehe Tabelle 6.30, „Standardtypen der wxWidgets-Abhängigkeiten“). Die folgenden Typen sind verfügbar:

Die Standardwerte für die einzelnen Komponenten sind in der folgenden Tabelle aufgeführt:

USE_WX=       2.4
WX_COMPS=     wx contrib

Die wxWidgets-Bibliotheken unterstützen Unicode seit der Version 2.5. In den Ports sind beide Versionen verfügbar und können über die folgenden Variablen ausgewählt werden:

Um eine bereits installierte Version zu finden, muss WANT_WX definiert werden. Falls diese Variable nicht auf eine bestimmte Versionsnummer gesetzt wird, werden die Komponenten einen Suffix mit der Versionsnummer tragen. Die Variable HAVE_WX wird gesetzt, falls eine installierte Version vorgefunden wurde.

WANT_WX=        yes

.include <bsd.port.pre.mk>

.if defined(WITH_WX) || ${HAVE_WX:Mwx-2.4} != ""
USE_WX=         2.4
CONFIGURE_ARGS+=--enable-wx
.endif

USE_WX=         2.6
WX_COMPS=       wx
WANT_WX=        2.6

.include <bsd.port.pre.mk>

.if defined(WITH_WXPYTHON) || ${HAVE_WX:Mpython} != ""
WX_COMPS+=      python
CONFIGURE_ARGS+=--enable-wxpython
.endif

Die folgenden Variablen sind in den Ports verfügbar (nachdem sie entsprechend Tabelle 6.24, „Variablen, um die wxWidgets-Version festzulegen“ definiert wurden).

Falls die Variablen gleich nach dem Importieren von bsd.port.pre.mk benutzt werden sollen, so muss die Variable WX_PREMK definiert werden.

USE_WX=         2.4
WX_PREMK=       yes

.include <bsd.port.pre.mk>

.if exists(${WX_CONFIG})
VER_STR!=       ${WX_CONFIG} --release

PLIST_SUB+=     VERSION="${VER_STR}"
.endif

Einige GNU configure-Skripte können wxWidgets nicht auffinden, falls nur die Umgebungsvariable WX_CONFIG gesetzt ist, sondern benötigen zusätzliche Argumente. Dafür kann die Variable WX_CONF_ARGS benutzt werden.

Es gibt viele Probleme bei der gleichzeitigen Verwendung unterschiedlicher Versionen von Lua-Bibliotheken (Dateien unterschiedlicher Versionen haben denselben Dateinamen). In den Ports wurde das Problem gelöst, indem jede Version unter einem eigenen Namen mit der Versionsnummer als Suffix installiert wird.

Der offensichtliche Nachteil dabei ist, dass jede Anwendung so verändert werden muss, dass sie die erwartete Version vorfindet. Dies kann jedoch durch zusätzliche Flags für Compiler und Linker gelöst werden.

Um festzulegen, welche Version von Lua verwendet werden soll, gibt es zwei Variablen (falls nur eine der beiden definiert ist, so wird die andere auf einen Standardwert gesetzt):

Es folgt eine Liste an möglichen Lua-Versionen und deren zugehöriger Port:

Die Variablen in Tabelle 6.34, „Variablen, um die Lua-Version festzulegen“ können auf einen oder mehrere (durch Leerzeichen getrennt) der folgenden Werte gesetzt werden:

Desweiteren gibt es Variablen, über die eine bevorzugte Version festgelegt werden kann. Die Versionen können als Liste angegeben werden, wobei die Reihenfolge der Priorisierung entspricht.

USE_LUA=      5.0-5.1
WANT_LUA_VER= 5.0

Desweiteren gibt es Anwendungen, die nicht direkt Lua-Bibliotheken sind, aber trotzdem mit diesen zusammenhängen. Diese Anwendungen können über die Variable LUA_COMPS festgelegt werden. Die folgenden Komponenten sind verfügbar:

Der Typ der Abhängigkeit kann für jede Komponente durch Hinzufügen eines Suffix (durch Strichpunkt getrennt) festgelegt werden. Falls der Typ nicht angegeben wird, wird ein Standardwert verwendet (siehe Tabelle 6.40, „Standardtypen für Lua-Abhängigkeiten“). Die folgenden Typen sind verfügbar:

Die Standardwerte für die einzelnen Komponenten sind in der folgenden Tabelle aufgeführt:

USE_LUA=      4.0
LUA_COMPS=    lua ruby

Um eine bereits installierte Version zu finden, muss WANT_LUA definiert werden. Falls diese Variable nicht auf eine bestimmte Versionsnummer gesetzt wird, werden die Komponenten einen Suffix mit der Versionsnummer tragen. Die Variable HAVE_LUA wird gesetzt, falls eine installierte Version vorgefunden wurde.

WANT_LUA=       yes

.include <bsd.port.pre.mk>

.if defined(WITH_LUA5) || ${HAVE_LUA:Mlua-5.[01]} != ""
USE_LUA=        5.0-5.1
CONFIGURE_ARGS+=--enable-lua5
.endif

USE_LUA=        4.0
LUA_COMPS=      lua
WANT_LUA=       4.0

.include <bsd.port.pre.mk>

.if defined(WITH_TOLUA) || ${HAVE_LUA:Mtolua} != ""
LUA_COMPS+=     tolua
CONFIGURE_ARGS+=--enable-tolua
.endif

Die folgenden Variablen sind in den Ports verfügbar (nachdem sie entsprechend Tabelle 6.34, „Variablen, um die Lua-Version festzulegen“ definiert wurden).

USE_LUA=        4.0
GNU_CONFIGURE=  yes
CONFIGURE_ENV=  CPPFLAGS="-I${LUA_INCDIR}" LDFLAGS="-L${LUA_LIBDIR}"

Falls die Variablen gleich nach dem Einbinden von bsd.port.pre.mk benutzt werden sollen, so muss die Variable LUA_PREMK definiert werden.

USE_LUA=        5.0
LUA_PREMK=      yes

.include <bsd.port.pre.mk>

.if exists(${LUA_CMD})
VER_STR!=       ${LUA_CMD} -v

CFLAGS+=        -DLUA_VERSION_STRING="${VER_STR}"
.endif

Es ist möglich, dass ein Dienst während der Deinstallation automatisch angehalten wird. Es wird empfohlen dieses Verhalten nur zu implementieren, wenn es unbedingt erforderlich ist zuerst den Dienst anzuhalten und dann die Dateien zu entfernen. Normalerweise sollte es dem Administrator überlassen werden, ob ein Dienst durch Deinstallieren angehalten werden soll. Dies betrifft auch den Vorgang des Aktualisierens.

Der Datei pkg-plist sollte eine Zeile wie folgt zugefügt werden:

@stopdaemon doormand

Das Argument muss dabei mit dem Inhalt der USE_RC_SUBR-Variablen übereinstimmen.

Bitte sorgen Sie dafür, dass ihre Ports bei der Deinstallation leere Verzeichnisse löschen. Dazu wird für jedes Verzeichnis, das der Port erzeugt hat, eine @dirrm-Zeile angegeben. Um ein Verzeichnis zu löschen müssen Sie zuerst dessen Unterverzeichnisse entfernen.

 :
lib/X11/oneko/pixmaps/cat.xpm
lib/X11/oneko/sounds/cat.au
 :
@dirrm lib/X11/oneko/pixmaps
@dirrm lib/X11/oneko/sounds
@dirrm lib/X11/oneko

Es kann allerdings auch vorkommen, dass @dirrm Fehler ausgibt, da andere Ports ein Verzeichnis ebenfalls nutzen. Deshalb können Sie @dirrmtry verwenden, um nur Verzeichnisse zu löschen, die wirklich leer sind, und damit Warnhinweise vermeiden.

@dirrmtry share/doc/gimp

Dadurch wird es weder eine Fehlermeldung geben noch wird pkg_delete(1) abnormal beendet werden - auch dann nicht, wenn ${PREFIX}/share/doc/gimp nicht leer ist, da andere Ports hier ebenfalls Dateien installiert haben.

Um leere Verzeichnisse während der Installation eines Ports zu erstellen, bedarf es etwas Aufmerksamkeit. Diese Verzeichnisse werden nicht erstellt, wenn das Paket installiert wird, da Pakete nur die Dateien speichern und pkg_add(1) nur die Verzeichnisse erstellt, die dafür benötigt werden. Um sicher zu gehen, dass das leere Verzeichnis erstellt wird, wenn ein Paket installiert wird, muss die folgende Zeile in pkg-plist über der entsprechenden @dirrm Zeile eingetragen werden:

@exec mkdir -p %D/share/foo/templates