Kapitel 6. Besonderheiten

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:

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:

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:

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.

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.

und

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:

und

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:

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

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:

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:

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/shared/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.

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.

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.

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:

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:

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

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

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.

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

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.

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 Ä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 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):

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}/shared/${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 Ä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.

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 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.

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 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 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:

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.

Die folgenden Variablen sind in den Ports verfügbar (nachdem sie entsprechend 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.

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 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.

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 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:

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.

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

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

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:

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