Kapitel 6. Besonderheiten

This translation may be out of date. To help with the translations please access the FreeBSD translations instance.

Es gibt einige Dinge mehr, die zu beachten sind, wenn man einen Port erstellt. Dieser Abschnitt erklärt die wichtigsten.

6.1. Shared-Libraries

Wenn Ihr Port eine oder mehrere Shared-Libraries installiert, dann definieren Sie bitte eine USE_LDCONFIG make-Variable, die bsd.port.mk anweisen wird, ${LDCONFIG} -m auf das Verzeichnis, in das die neue Library installiert wird (normalerweise PREFIX/lib), während des post-install-Targets anzuwenden, um sie im Shared-Library-Cache zu registrieren. Diese Variable, wenn definiert, wird auch dafür sorgen, dass ein entsprechendes @exec /sbin/ldconfig -m und @unexec /sbin/ldconfig -R-Paar zu Ihrer pkg-plist-Datei hinzugefügt wird, sodass ein Benutzer, der das Paket installiert, die Bibliothek danach sofort benutzen kann und das System nach deren Deinstallation nicht glaubt, die Bibliothek wäre noch da.

USE_LDCONFIG= yes

Wenn nötig, können Sie das Standardverzeichnis außer Kraft setzen, indem Sie den USE_LDCONFIG Wert auf eine Liste von Verzeichnissen setzen, in die Shared Libraries installiert werden sollen. Wenn Ihr Port z.B. diese Bibliotheken nach PREFIX/lib/foo und PREFIX/lib/bar installiert, könnten Sie folgendes in Ihrem Makefile benutzen:

USE_LDCONFIG= ${PREFIX}/lib/foo ${PREFIX}/lib/bar

Bitte überprüfen Sie dies genau. Oft ist das überhaupt nicht nötig oder kann durch -rpath oder das Setzen von LD_RUN_PATH während des Linkens umgangen werden (s. lang/moscow_ml für ein Beispiel), oder durch einen Shell-Wrapper, der LD_LIBRARY_PATH setzt, bevor er die Binärdatei ausführt, wie es www/seamonkey tut.

Wenn Sie 32-Bit Libraries auf 64-Bit Systemen installieren, benutzen Sie stattdessen USE_LDCONFIG32.

Versuchen Sie Shared-Library-Versionsnummern im libfoo.so.0 Format zu halten. Unser Runtime-Linker kümmert sich nur um die Major (erste) Nummer.

Wenn sich die Major-Library-Versionsnummer während der Aktualisierung zu einer neuen Portversion erhöht, sollte auch die PORTREVISION aller Ports, die die Shared-Library linken, erhöht werden, damit diese mit der neuen Version der Bibliothek neu kompiliert werden.

6.2. Ports mit beschränkter Verbreitung

Lizenzen variieren und manche geben Restriktionen vor, wie die Applikation gepackt werden oder ob sie gewinnorientiert verkauft werden kann, usw.

Es liegt in Ihrer Verantwortung als Porter die Lizenzbestimmungen der Software zu lesen und sicherzustellen, dass das FreeBSD-Projekt nicht haftbar gemacht wird für Lizenzverletzungen durch Weiterverbreitung des Quelltextes oder kompilierter Binaries über FTP/HTTP oder CD-ROM. Im Zweifelsfall kontaktieren Sie bitte die FreeBSD ports.

In solchen Situationen können die in den folgenden Abschnitten beschriebenen Variablen gesetzt werden.

6.2.1. `NO_PACKAGE`

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.

6.2.2. `NO_CDROM`

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.

6.2.3. `NOFETCHFILES`

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.

6.2.4. `RESTRICTED`

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.

6.2.5. `RESTRICTED_FILES`

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.

6.3. Build-Mechanismen

6.3.1. Paralleles Bauen von Ports

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.

6.3.2. `make`, `gmake` und `imake`

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

Tabelle 1. Port-Variablen im Zusammenhang mit gmake
Variable	Bedeutung
`USE_GMAKE`	Der Port benötigt `gmake` für den Build.
`GMAKE`	Der ganze Pfad zu `gmake`, wenn es nicht im `PATH` ist.

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.

6.3.3. `configure` Skript

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.

Tabelle 2. Variablen für Ports, die `configure` benutzen
Variable	Bedeutung
`GNU_CONFIGURE`	Der Port benutzt ein `configure`-Skript, um das Bauen vorzubereiten.
`HAS_CONFIGURE`	Wie `GNU_CONFIGURE`, nur dass kein Standard-Konfigurations-Target zu `CONFIGURE_ARGS` hinzugefügt wird.
`CONFIGURE_ARGS`	Zusätzliche Argumente für das `configure`-Skript.
`CONFIGURE_ENV`	Zusätzliche Umgebungsvariablen für die Abarbeitung des `configure`-Skriptes.
`CONFIGURE_TARGET`	Ersetzt das Standard-Konfigurations-Target. Vorgabewert ist `${MACHINE_ARCH}-portbld-freebsd${OSREL}`.

6.3.4. Benutzung von `scons`

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

Tabelle 3. Variablen für Ports, die `scons` benutzen
Variable	Bedeutung
`SCONS_ARGS`	Port-spezifische SCons-Argumente, die der SCons-Umgebung übergeben werden.
`SCONS_BUILDENV`	Variablen, die in der System-Umgebung gesetzt werden sollen.
`SCONS_ENV`	Variablen, die in der SCons-Umgebung gesetzt werden sollen.
`SCONS_TARGET`	Letztes Argument, das SCons übergeben wird - ähnlich `MAKE_TARGET`.

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.

6.4. Benutzung von GNU autotools

6.4.1. Einführung

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.

6.4.2. `libtool`

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.

6.4.3. `libltdl`

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.

6.4.4. `autoconf` und `autoheader`

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.

6.4.5. `automake` und `aclocal`

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.

6.5. Benutzung von GNU `gettext`

6.5.1. Grundlegende Benutzung

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"

6.5.2. Optionale Benutzung

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.

6.5.3. Behandlung von Message-Catalog-Verzeichnissen

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.

6.6. Die Benutzung von `perl`

Wenn MASTER_SITES auf MASTER_SITE_PERL_CPAN gesetzt ist, dann ist der bevorzugte Wert von MASTER_SITE_SUBDIR der Top-Level-Name der Hierarchie. Zum Beispiel ist der empfohlene Wert für p5-Module-Name-Module. Die Top-Level-Hierarchie kann unter cpan.org angeschaut werden. Dies sorgt dafür, dass der Port weiter funktioniert, wenn sich der Autor des Moduls ändert.

Die Ausnahme dieser Regel ist, dass das entsprechende Verzeichnis selber oder das Distfile in diesem Verzeichnis nicht existiert. In solchen Fällen ist die Benutzung der Id des Autors als MASTER_SITE_SUBDIR erlaubt.

Jede der Einstellungen unten kann sowohl auf YES als auch auf eine Versionszeichenkette wie 5.8.0+ gesetzt werden. Wenn YES benutzt wird, bedeutet das, dass der Port mit jeder der unterstützten Perl-Versionen funktioniert. Falls ein Port nur mit einer bestimmten Perl-Version funktioniert, kann darauf mit einer Versionszeichenkette hingewiesen werden, die entweder eine Mindest- (z.B. 5.7.3+), Maximal- (z.B. 5.8.0-) oder Absolutversion (z.B. 5.8.3) festlegt.

Tabelle 4. Variablen für Ports, die `perl` benutzen
Variable	Bedeutung
`USE_PERL5`	Bedeutet, dass der Port `perl 5` zum Erstellen und zum Ausführen benutzt.
`USE_PERL5_BUILD`	Bedeutet, dass der Port `perl 5` zum Erstellen benutzt.
`USE_PERL5_RUN`	Bedeutet, dass der Port `perl 5` zur Laufzeit benutzt.
`PERL`	Der gesamte Pfad zu `perl 5` - entweder im Basissystem oder nachinstalliert über einen Port - ohne die Versionsnummer. Benutzen Sie diese Variable, wenn Sie “#!”-Zeilen in Skripten ersetzen müssen.
`PERL_CONFIGURE`	Perls MakeMaker für die Konfiguration benutzen. Dies impliziert `USE_PERL5`.
`PERL_MODBUILD`	Module::Build für configure, build und install benutzen. Dies impliziert `PERL_CONFIGURE`.

Ports von Perl-Modulen, die keine offizielle Webseite haben, sollen in der WWW-Zeile ihrer pkg-descr-Datei auf cpan.org verlinken. Die bevorzugte URL-Form ist http://search.cpan.org/dist/Module-Name/ (inklusive des Slash am Ende).

6.7. Benutzung von X11

6.7.1. X.Org-Komponenten

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.

Beispiel 1. Beispiel für USE_XORG

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.

Tabelle 5. Variablen für Ports, die X benutzen
`USE_XLIB`	Der Port benutzt die X-Bibliotheken. Soll nicht mehr verwendet werden - benutzen Sie stattdessen eine Liste von Komponenten in `USE_XORG`.
`USE_X_PREFIX`	Soll nicht mehr benutzt werden, ist jetzt äquivalent zu `USE_XLIB` und kann einfach durch letzteres ersetzt werden.
`USE_IMAKE`	Der Port benutzt `imake`. Impliziert `USE_X_PREFIX`.
`XMKMF`	Ist auf den Pfad zu `xmkmf` gesetzt, wenn nicht in `PATH`. Vorgabe ist `xmkmf -a`.

Tabelle 6. Variablen bei Abhängigkeit von einzelnen Teilen von X11
`X_IMAKE_PORT`	Ein Port, der `imake` und einige andere Werkzeuge, die zum Erstellen von X11 benutzt werden, bereitstellt.
`X_LIBRARIES_PORT`	Ein Port, der die X11-Bibliotheken bereitstellt.
`X_CLIENTS_PORT`	Ein Port, der X11-Clients bereitstellt.
`X_SERVER_PORT`	Ein Port, der den X11-Server bereitstellt.
`X_FONTSERVER_PORT`	Ein Port, der den Fontserver bereitstellt.
`X_PRINTSERVER_PORT`	Ein Port, der den Printserver bereitstellt.
`X_VFBSERVER_PORT`	Ein Port, der den virtuellen Framebuffer-Server bereitstellt.
`X_NESTSERVER_PORT`	Ein Port, der einen nested X-Server bereitstellt.
`X_FONTS_ENCODINGS_PORT`	Ein Port, der Kodierungen für Schriftarten bereitstellt.
`X_FONTS_MISC_PORT`	Ein Port, der verschiedene Bitmap-Schriftarten bereitstellt.
`X_FONTS_100DPI_PORT`	Ein Port, der 100dpi Bitmap-Schriftarten bereitstellt.
`X_FONTS_75DPI_PORT`	Ein Port, der 75dpi Bitmap-Schriftarten bereitstellt.
`X_FONTS_CYRILLIC_PORT`	Ein Port, der kyrillische Bitmap-Schriftarten bereitstellt.
`X_FONTS_TTF_PORT`	Ein Port, der TrueType®-Schriftarten bereitstellt.
`X_FONTS_TYPE1_PORT`	Ein Port, der Type1-Schriftarten bereitstellt.
`X_MANUALS_PORT`	Ein Port, der entwicklerorientierte Manualpages bereitstellt.

Beispiel 2. Benutzung von X11-bezogenen Variablen in einem Port

# 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

6.7.2. Ports, die Motif benötigen

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:

Wenn sich der Port in seinem Makefile oder Imakefile auf die Motif-Bibliothek als -lXm bezieht, ersetzen Sie das einfach durch ${MOTIFLIB}.
Wenn der Port in seinem ImakefileXmClientLibs benutzt, ersetzen Sie das durch ${MOTIFLIB} ${XTOOLLIB} ${XLIB}.

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.

6.7.3. X11 Schriftarten

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

6.7.4. Erzeugen eines künstlichen `DISPLAY` durch Xvfb

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

6.7.5. Desktop-Einträge

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

6.8. Benutzung von GNOME

Das FreeBSD/GNOME-Projekt benutzt seine eigene Gruppe von Variablen, um zu definieren, welche GNOME-Komponenten ein bestimmter Port benutzt. Eine umfassende Liste dieser Variablen existiert innerhalb der Webseite des FreeBSD/GNOME-Projektes.

6.9. Benutzung von Qt

6.9.1. Ports, die Qt benötigen

Tabelle 7. Variablen für Ports, die Qt benötigen
`USE_QT_VER`	Der Port benutzt das Qt-Toolkit. Mögliche Werte sind `3` und `4`; diese spezifizieren die Major Version von Qt, die benutzt werden soll. Entsprechende Parameter werden an das `configure`-Skript und `make` übergeben.
`QT_PREFIX`	Enthält den Pfad, wohin Qt installiert ist (nur lesbare Variable).
`MOC`	Enthält den Pfad von `moc` (nur lesbare Variable). Voreingestellt entsprechend des `USE_QT_VER`-Werts.
`QTCPPFLAGS`	Zusätzliche Compiler-Flags, die über `CONFIGURE_ENV` an das Qt-Toolkit übergeben werden. Voreingestellt entsprechend des `USE_QT_VER`-Wertes.
`QTCFGLIBS`	Zusätzliche Bibliotheken, die über `CONFIGURE_ENV` für das Qt-Toolkit gelinkt werden sollen. Voreingestellt entsprechend des `USE_QT_VER`-Wertes.
`QTNONSTANDARD`	Änderungen von `CONFIGURE_ENV`, `CONFIGURE_ARGS` und `MAKE_ENV` sollen unterdrückt werden.

Tabelle 8. Zusätzliche Variablen für Ports, die Qt 4.xi benutzen
`QT_COMPONENTS`	Spezifiziert Tool- und Bibliothek-Abhängigkeiten für Qt4. Siehe unten für Details.
`UIC`	Enthält den Pfad von `uic` (nur lesbare Variable). Voreingestellt entsprechend des `USE_QT_VER`-Wertes.
`QMAKE`	Enthält den Pfad von `qmake` (nur lesbare Variable). Voreingestellt entsprechend des `USE_QT_VER`-Wertes.
`QMAKESPEC`	Enthält den Pfad der Konfigurationsdatei für `qmake` (nur lesbare Variable). Voreingestellt entsprechend des `USE_QT_VER`-Wertes.

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}"

6.9.2. Komponentenauswahl (nur bei Qt 4.x)

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

Tabelle 9. Verfügbare Qt4-Bibliothekskomponenten
Name	Beschreibung
`corelib`	Kern-Bibliothek (kann weggelassen werden- es sei denn, der Port benutzt nichts außer `corelib`)
`gui`	Graphische Benutzeroberflächen-Bibliothek
`network`	Netzwerk-Bibliothek
`opengl`	OpenGL-Bibliothek
`qt3support`	Qt3-Kompatibilitäts-Bibliothek
`qtestlib`	Modultest-Bibliothek
`script`	Skript-Bibliothek
`sql`	SQL-Bibliothek
`xml`	XML-Bibliothek

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

Tabelle 10. Verfügbare Qt4-Tool-Komponenten
Name	Beschreibung
`moc`	meta object compiler (wird zum Build fast jeder Qt-Applikation benötigt)
`qmake`	Makefile-Generator / Build-Werkzeug
`rcc`	Resource-Compiler (wird benötigt, falls die Applikation .rc oder .qrc Dateien enthält)
`uic`	User-Interface-Compiler (wird benötigt, falls die Applikation von Qt-Designer erzeugte *.ui Dateien enthält - gilt für praktisch jede Qt-Applikation mit einer GUI)

Tabelle 11. Verfügbare Qt4-Plugin-Komponenten
Name	Beschreibung
`iconengines`	SVG-Icon-Engine Plugin (wenn die Applikation SVG-Icons mitliefert)
`imageformats`	Bildformatplugins für GIF, JPEG, MNG und SVG (wenn die Applikation Bilddateien mitliefert)

Beispiel 3. Qt4-Komponenten auswählen

In diesem Beispiel benutzt die portierte Applikation die Qt4 GUI-Bibliothek, die Qt4-Core-Bibliothek, alle Qt4-Codeerzeugungstools und Qt4’s Makefile Generator. Da die GUI-Bibliothek eine Abhängigkeit von der Core-Bibliothek impliziert, muss corelib nicht angegeben werden. Die Qt4-Codeerzeugungstools moc, uic und rcc, sowie der Makefile Generator qmake werden nur für den Build benötigt, deshalb bekommen die den Suffix _build:

USE_QT_VER=    4
QT_COMPONENTS= gui moc_build qmake_build rcc_build uic_build

6.9.3. Zusätzliche Besonderheiten

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

Fehlende zusätzliche Include-Pfade. Viele Applikationen kommen mit System-Tray-Icon Support- unterlassen es aber Includes oder Bibliotheken in den X11 Verzeichnissen zu suchen. Sie können qmake über die Kommandozeile sagen, es soll Verzeichnisse zu den Include- und Bibliotheks-Suchpfaden hinzufügen - z.B.:
```
${QMAKE} -unix PREFIX=${PREFIX} INCLUDEPATH+=${LOCALBASE}/include \
    LIBS+=-L${LOCALBASE}/lib sillyapp.pro
```
Falsche Installations-Pfade. Manchmal werden Daten wie Icons oder .desktop-Dateien per Vorgabe in Verzeichnisse installiert, die nicht von XDG-kompatiblen Applikationen durchsucht werden. editors/texmaker ist hierfür ein Beispiel- siehe patch-texmaker.pro im files-Verzeichnis dieses Ports als eine Vorlage, die zeigt, wie man dies direkt in der Qmake Projektdatei löst.

6.10. Benutzung von KDE

6.10.1. Variablen-Definitionen (KDE 3)

Tabelle 12. Variablen für Ports, die KDE 3 benutzen
`USE_KDELIBS_VER`	Der Port benutzt KDE-Bibliotheken. Die Variable spezifiziert die Major Version von KDE, die benutzt werden soll, und impliziert `USE_QT_VER` der entsprechenden Version. Der einzig mögliche Wert ist `3`.
`USE_KDEBASE_VER`	Der Port benutzt die KDE-Base. Die Variable spezifiziert die Major Version von KDE, die benutzt werden soll, und impliziert `USE_QT_VER` der entsprechenden Version. Der einzig mögliche Wert ist `3`.

6.10.2. Variablen-Definitionen (KDE 4)

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

Tabelle 13. Verfügbare KDE 4-Komponenten
Name	Beschreibung
`akonadi`	Personal Information Management (PIM)-Speicherdienst
`automoc4`	Lässt den Port das Bauwerkzeug automoc4 verwenden.
`kdebase`	Grundlegende KDE-Anwendungen (Konqueror, Dolphin, Konsole)
`kdeexp`	Experimentelle KDE-Bibliotheken (mit einer API, die als non-stable eingestuft ist)
`kdehier`	Stellt allgemeine KDE-Verzeichnisse bereit
`kdelibs`	Die grundlegenden KDE-Bibliotheken
`kdeprefix`	Falls in der Liste vorhanden, wird der Port unter `${KDE4_PREFIX}` statt `${LOCALBASE}` installiert
`pimlibs`	PIM-Bibliotheken
`workspace`	Anwendungen und Bibliotheken, welche die Desktopumgebung gestalten (Plasma, KWin)

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.

Beispiel 4. USE_KDE4-Beispiel

Dies ist ein einfaches Beispiel für einen KDE 4-Port. USE_CMAKE weist den Port an, CMake, ein unter KDE 4-Projekten weit verbreitetes Konfigurationswerkzeug, zu verwenden. USE_KDE4 legt die Abhängigkeit von KDE-Bibliotheken und die Verwendung von automoc4 während der Kompilierung fest. Mit Hilfe des configure-Protokolls können die KDE-Komponenten und andere Abhängigkeiten festgestellt werden. USE_KDE4 impliziert USE_QT_VER nicht. Falls der Port Qt 4-Komponenten benötigt, sollten USE_QT_VER gesetzt und verlangte Komponenten festgelegt werden.

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

6.11. Benutzung von Java

6.11.1. Variablen-Definitionen

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.

Tabelle 14. Variablen, die von Ports, die Java benutzen, gesetzt werden müssen
Variable	Bedeutung
`USE_JAVA`	Sollte definiert sein, damit die übrigen Variablen irgendeinen Effekt haben.
`JAVA_VERSION`	Durch Leerzeichen getrennte Liste von geeigneten Java-Versionen für den Port. Ein optionales ""` ermöglicht die Angabe eines Bereiches von Versionen (mögliche Werte: `1.5[] 1.6[] 1.7[]).
`JAVA_OS`	Durch Leerzeichen getrennte Liste von geeigneten JDK-Port-Betriebssystemen für den Port. (erlaubte Werte: `native linux`).
`JAVA_VENDOR`	Durch Leerzeichen getrennte Liste von geeigneten JDK-Port-Anbietern für den Port. (erlaubte Werte: `freebsd bsdjava sun openjdk`).
`JAVA_BUILD`	Bedeutet, falls gesetzt, dass der ausgewählte JDK-Port zu den Build-Abhängigkeiten des Ports hinzugefügt werden soll.
`JAVA_RUN`	Bedeutet, falls gesetzt, dass der ausgewählte JDK-Port zu den Laufzeit-Abhängigkeiten des Ports hinzugefügt werden soll.
`JAVA_EXTRACT`	Bedeutet, falls gesetzt, dass der ausgewählte JDK-Port zu den Extract-Abhängigkeiten des Ports hinzugefügt werden soll.

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

Tabelle 15. Bereitgestellte Variablen für Ports, die Java benutzen
Variable	Wert
`JAVA_PORT`	Der Name des JDK-Ports (z.B. `'java/diablo-jdk16'`).
`JAVA_PORT_VERSION`	Die volle Version des JDK Ports (z.B. `'1.6.0'`). Wenn Sie nur die ersten beiden Stellen dieser Versionsnummer benötigen, benutzen Sie `${JAVA_PORT_VERSION:C/^([0-9])\.([0-9])(.*)$/\1.\2/}`.
`JAVA_PORT_OS`	Das vom JDK-Port benutzte Betriebssystem (z.B. `'native'`).
`JAVA_PORT_VENDOR`	Der Anbieter des JDK-Ports (z.B. `'freebsd'`).
`JAVA_PORT_OS_DESCRIPTION`	Beschreibung des vom JDK-Port benutzten Betriebssystems (z.B. `'Native'`).
`JAVA_PORT_VENDOR_DESCRIPTION`	Beschreibung des Anbieters des JDK-Ports (z.B. `'FreeBSD Foundation'`).
`JAVA_HOME`	Pfad zum Installationsverzeichnis des JDK (z.B. '/usr/local/diablo-jdk1.6.0').
`JAVAC`	Pfad zum Java-Compiler, der benutzt werden soll (z.B. '/usr/local/diablo-jdk1.6.0/bin/javac'.
`JAR`	Pfad zum `jar`-Werkzeug, das benutzt werden soll (z.B.''/usr/local/diablo-jdk1.6.0/bin/jar oder '/usr/local/bin/fastjar').
`APPLETVIEWER`	Pfad zum `appletviewer`-Werkzeug (z.B. '/usr/local/diablo-jdk1.6.0/bin/appletviewer').
`JAVA`	Pfad zur `java` Binärdatei. Benutzen Sie dies, um Java-Programme auszuführen (z.B.'/usr/local/diablo-jdk1.6.0/bin/java').
`JAVADOC`	Pfad zum `javadoc`-Werkzeug.
`JAVAH`	Pfad zum `javah`-Programm.
`JAVAP`	Pfad zum `javap`-Programm.
`JAVA_KEYTOOL`	Pfad zum `keytool`-Werkzeug.
`JAVA_N2A`	Pfad zum `native2ascii`-Werkzeug.
`JAVA_POLICYTOOL`	Pfad zum `policytool` Programm.
`JAVA_SERIALVER`	Pfad zum `serialver`-Werkzeug.
`RMIC`	Pfad zum RMI Stub/Skeleton-Generator, `rmic`.
`RMIREGISTRY`	Pfad zum RMI Registry-Werkzeug, `rmiregistry`.
`RMID`	Pfad zum RMI Daemon `rmid`.
`JAVA_CLASSES`	Pfad zum Archiv, das die JDK-Klassendateien enthält, ${JAVA_HOME}/jre/lib/rt.jar.

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:

Tabelle 16. Konstanten, die für Ports, welche Java benutzen, definiert sind
Konstante	Wert
`JAVASHAREDIR`	Das Basis-Verzeichnis für alles, was mit Java zusammenhängt. Standardmäßig ${PREFIX}/shared/java.
`JAVAJARDIR`	Das Verzeichnis, wohin JAR-Dateien installiert werden sollen. Standardmäßig ${JAVASHAREDIR}/classes.
`JAVALIBDIR`	Das Verzeichnis, in dem JAR-Dateien, die von anderen Ports installiert wurden, liegen. Standardmäßig ${LOCALBASE}/shared/java/classes.

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.

6.11.2. Kompilieren mit Ant

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.

6.11.3. Optimales Verfahren

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

6.12. Webanwendungen, Apache und PHP

6.12.1. Apache

Tabelle 17. Variablen für Ports, die Apache verwenden
`USE_APACHE`	Der Port benötigt Apache. Mögliche Werte: `yes` (beliebige Version), `1.3`, `2.0`, `2.2`, `2.0+`, etc. - Standard ist Version `1.3`.
`WITH_APACHE2`	Der Port benötigt Apache 2.0. Ist diese Variable nicht gesetzt, so benötigt der Port Apache 1.3. Diese Variable ist veraltet und sollte nicht mehr verwendet werden.
`APXS`	Vollständiger Pfad zu der `apxs` Binärdatei. Die Variable kann neu gesetzt werden.
`HTTPD`	Vollständiger Pfad zu der `httpd` Binärdatei. Die Variable kann neu gesetzt werden.
`APACHE_VERSION`	Beinhaltet die Versionsnummer des aktuell installierten Apache (nur lesbare Variable). Diese Variable ist nach Einbinden der Datei bsd.port.pre.mk verfügbar. Mögliche Werte: `13`, `20`, `22`.
`APACHEMODDIR`	Verzeichnis der Apache-Module. Diese Variable wird automatisch in pkg-plist ersetzt.
`APACHEINCLUDEDIR`	Verzeichnis der Apache Header-Dateien. Diese Variable wird automatisch in pkg-plist ersetzt.
`APACHEETCDIR`	Verzeichnis der Apache-Konfigurationsdateien. Diese Variable wird automatisch in pkg-plist ersetzt.

Tabelle 18. Nützliche Variablen für Ports von Apache-Modulen
`MODULENAME`	Name des Moduls. Standardwert ist `PORTNAME`. Beispiel: `mod_hello`
`SHORTMODNAME`	Der gekürzte Name des Moduls. Standardmäßig wird der Wert von `MODULENAME` übernommen. Beispiel: `hello`
`AP_FAST_BUILD`	Verwende `apxs` zum Kompilieren und Installieren des Moduls.
`AP_GENPLIST`	Eine pkg-plist wird automatisch erzeugt.
`AP_INC`	Verzeichnis für zusätzliche Header-Dateien, die beim Kompilieren mitverwendet werden.
`AP_LIB`	Verzeichnis für zusätzliche Bibliothek-Dateien, welche beim Kompilieren mitverwendet werden.
`AP_EXTRAS`	Zusätzliche Flags für `apxs`.

6.12.2. Webanwendungen

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.

6.12.3. PHP

Tabelle 19. Variablen für Ports, die PHP verwenden
`USE_PHP`	Der Port benötigt PHP. Der Wert `yes` bewirkt eine Abhängigkeit des Ports von PHP. Es kann auch eine Liste der benötigten PHP-Erweiterungen angegeben werden. Beispiel: `pcre xml gettext`
`DEFAULT_PHP_VER`	Legt die Version von PHP fest, die standardmäßig installiert wird, falls noch kein PHP vorhanden ist. Standardwert ist `4`. Mögliche Werte sind: `4`,`5`
`IGNORE_WITH_PHP`	Der Port funktioniert nicht mit der angegebenen Version von PHP. Mögliche Werte: `4`, `5`
`USE_PHPIZE`	Der Port wird als PHP-Erweiterung gebaut.
`USE_PHPEXT`	Der Port wird wie eine PHP-Erweiterung behandelt - Installation und Eintragung in die PHP-Registry für Erweiterungen.
`USE_PHP_BUILD`	Setzt PHP als build-Anhängigkeit.
`WANT_PHP_CLI`	Benötigt die Kommandozeilen-Version von PHP.
`WANT_PHP_CGI`	Benötigt die CGI-Version von PHP.
`WANT_PHP_MOD`	Benötigt das Apache-Modul von PHP.
`WANT_PHP_SCR`	Benötigt die Kommandozeilen- oder die CGI-Version von PHP.
`WANT_PHP_WEB`	Benötigt das Apache-Modul oder die CGI-Version von PHP.

6.12.4. PEAR Module

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.

Beispiel 5. Beispiel eines Makefiles für eine PEAR Klasse

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>

6.13. Python benutzen

Die Ports unterstützen parallele Installationen mehrerer Python-Versionen. Ports sollten sicherstellen, dass der richtige python-Interpreter verwendet wird - entsprechend der durch den Benutzer definierbaren Variable PYTHON_VERSION. Häufig bedeutet dies, dass der Pfad zum python-Interpreter durch den Wert der Variablen PYTHON_CMD ersetzt werden muss.

Ports, die Dateien unter PYTHON_SITELIBDIR installieren, sollten pyXY- als Präfix des Paketnamens haben, sodass in deren Paketname die zugehörige Python Version aufgeführt wird.

PKGNAMEPREFIX= ${PYTHON_PKGNAMEPREFIX}

Tabelle 20. Nützliche Variablen für Ports, die Python verwenden
`USE_PYTHON`	Der Port benötigt Python. Die minimal benötigte Version kann durch Werte wie `2.3+` angegeben werden. Bereiche von Versionsnummern können durch Angabe der minimalen und maximalen Versionsnummer, getrennt durch einen Gedankenstrich, festgelegt werden, z.B.: `2.1-2.3`
`USE_PYDISTUTILS`	Verwende Python-distutils zum Konfigurieren, Kompilieren und Installieren. Dies ist erforderlich, falls der Port eine setup.py-Datei beinhaltet. Dadurch werden die `do-build` und `do-install`-Ziele und eventuell auch das `do-configure`-Ziel übergangen, falls `GNU_CONFIGURE` nicht definiert ist.
`PYTHON_PKGNAMEPREFIX`	Wird als `PKGNAMEPREFIX` verwendet, um Pakete für unterschiedliche Python-Versionen zu trennen. Beispiel: `py24-`
`PYTHON_SITELIBDIR`	Verzeichnis des site-Pakete Baums, der das Installationsverzeichnis von Python (üblicherweise `LOCALBASE`) beinhaltet. Die `PYTHON_SITELIBDIR`-Variable kann sehr nützlich bei der Installation von Python-Modulen sein.
`PYTHONPREFIX_SITELIBDIR`	Die präfix-freie Variante von `PYTHON_SITELIBDIR`. Benutzen Sie immer `%%PYTHON_SITELIBDIR%%` in pkg-plist, wenn möglich. Der Standardwert von `%%PYTHON_SITELIBDIR%%` ist `lib/python%%PYTHON_VERSION%%/site-packages`
`PYTHON_CMD`	Kommandozeilen-Interpreter für Python mit Versionsnummer.
`PYNUMERIC`	Liste der Abhängigkeiten für numerische Erweiterungen.
`PYNUMPY`	Liste der Abhängigkeiten für die neue numerische Erweiterung numpy. (`PYNUMERIC` ist vom Anbieter als veraltet deklariert)
`PYXML`	Liste der Abhängigkeiten für XML-Erweiterungen (wird ab Python 2.0 nicht mehr benötigt, da im Basispaket enthalten).
`USE_TWISTED`	Setzt die Abhängigkeit des Ports von twistedCore. Die Liste der erforderlichen Komponenten kann als Wert spezifiziert werden. Beispiel: `web lore pair flow`
`USE_ZOPE`	Setzt Zope, eine Plattform für Webanwendungen, als Abhängigkeit des Ports. Setzt die Versionsabhängigkeit von Python auf 2.3. Setzt `ZOPEBASEDIR` auf das Verzeichnis, in welches Zope installiert wurde.

Eine vollständige Liste aller verfügbaren Variablen ist in /usr/ports/Mk/bsd.python.mk zu finden.

6.14. Benutzung von Tcl/Tk

Die Ports-Sammlung unterstützt die parallele Installation mehrerer Tcl/Tk-Versionen. Ports sollten mindestens die vorgegebene Tcl/Tk-Version oder höher zu unterstützen versuchen anhand der Variablen USE_TCL und USE_TK. Es ist möglich, die gewünschte Version von tcl mit der Variable WITH_TCL_VER vorzuschreiben.

Tabelle 21. Äußerst nützliche Variablen für Ports, die Tcl/Tk benutzen
`USE_TCL`	Der Port benötigt die Tcl-Bibliothek (nicht die Shell). Eine notwendige Mindestversion kann mit Werten wie 84+ angegeben werden. Einzelne nicht unterstützte Versionen können mit der Variable `INVALID_TCL_VER` festgelegt werden.
`USE_TCL_BUILD`	Der Port benötigt Tcl nur während der Zeit, in der er gebaut wird.
`USE_TCL_WRAPPER`	Ports, welche zwar die Tcl-Shell, aber nicht eine bestimmte Version von `tclsh` verlangen, sollten diese neue Variable verwenden. Ein Wrapperskript für `tclsh` wird auf dem System installiert. Der Benutzer kann festlegen, welche `tcl`-Shell gewünscht ist bzw. verwendet werden soll.
`WITH_TCL_VER`	Benutzerdefinierte Variable, welche die gewünschte Tcl-Version bestimmt.
`_PORTNAME__WITH_TCL_VER`	Gleich wie `WITH_TCL_VER`, nur portspezifisch.
`USE_TCL_THREADS`	Fordere threadfähiges Tcl/Tk.
`USE_TK`	Der Port benötigt die Tk-Bibliothek (nicht die Wish-Shell). Impliziert `USE_TCL` mit dem gleichen Wert. Für weitere Informationen siehe die Beschreibung der Variable `USE_TCL`.
`USE_TK_BUILD`	Analog zur Variable `USE_TCL_BUILD`.
`USE_TK_WRAPPER`	Analog zur Variable `USE_TCL_WRAPPER`.
`WITH_TK_VER`	Analog zur Variable `WITH_TCL_VER` und impliziert `WITH_TCL_VER` mit dem gleichen Wert.

Eine vollständige Liste der zur Verfügung stehenden Variablen befindet sich in /usr/ports/Mk/bsd.tcl.mk.

6.15. Emacs benutzen

Dieser Abschnitt muss noch geschrieben werden.

6.16. Ruby benutzen

Tabelle 22. Nützliche Variablen für Ports, die Ruby verwenden
Variable	Description
`USE_RUBY`	Der Port benötigt Ruby.
`USE_RUBY_EXTCONF`	Der Port verwendet extconf.rb für die Konfiguration.
`USE_RUBY_SETUP`	Der Port verwendet setup.rb für die Konfiguration.
`RUBY_SETUP`	Legt den alternativen Namen von setup.rb fest. Üblich ist der Wert install.rb.

Die folgende Tabelle listet ausgewählte Variablen auf, die Portautoren über die Port-Infrastruktur zur Verfügung stehen. Diese Variablen sollten für die Installation von Dateien in die entsprechenden Verzeichnisse verwendet werden. Sie sollten in pkg-plist so häufig wie möglich verwendet und in einem Port nicht neu definiert werden.

Tabelle 23. Ausgewählte read-only-Variablen für Ports, die Ruby verwenden
Variable	Beschreibung	Beispiel
`RUBY_PKGNAMEPREFIX`	Wird als `PKGNAMEPREFIX` verwendet, um Pakete für verschiedene Versionen von Ruby zu unterscheiden.	`ruby18-`
`RUBY_VERSION`	Vollständige Version von Ruby in der Form `x.y.z`.	`1.8.2`
`RUBY_SITELIBDIR`	Installationsverzeichnis der von der Rechnerarchitektur unabhängigen Bibliotheken.	`/usr/local/lib/ruby/site_ruby/1.8`
`RUBY_SITEARCHLIBDIR`	Installationsverzeichnis der von der Rechnerarchitektur abhängigen Bibliotheken.	`/usr/local/lib/ruby/site_ruby/1.8/amd64-freebsd6`
`RUBY_MODDOCDIR`	Installationsverzeichnis für die Dokumentation der Module.	`/usr/local/shared/doc/ruby18/patsy`
`RUBY_MODEXAMPLESDIR`	Installationsverzeichnis für die Beispiele der Module.	`/usr/local/shared/examples/ruby18/patsy`

Eine vollständige Liste der verfügbarenVariablen kann in /usr/ports/Mk/bsd.ruby.mk eingesehen werden.

6.17. SDL verwenden

Die Variable USE_SDL wird für die automatische Konfiguration der Abhängigkeiten für Ports benutzt, die auf SDL basierende Bibliotheken wie devel/sdl12 und x11-toolkits/sdl_gui verwenden.

Die folgenden SDL-Bibliotheken sind derzeit bekannt:

Falls ein Port z.B. von net/sdl_net und audio/sdl_mixer abhängt, so wäre die Syntax:

USE_SDL=        net mixer

Die Abhängigkeit von devel/sdl12, die durch net/sdl_net und audio/sdl_mixer entsteht, wird automatisch zum Port hinzugefügt.

Falls USE_SDL im Port verwendet wird, so wird automatisch:

die Abhängigkeit von sdl12-config zu BUILD_DEPENDS hinzugefügt
die Variable SDL_CONFIG zu CONFIGURE_ENV hinzugefügt
die Abhängigkeit der ausgewählten Bibliotheken zu LIB_DEPENDS hinzugefügt

Um zu überprüfen, ob die SDL-Bibliotheken verfügbar sind, kann die Variable WANT_SDL verwendet werden:

WANT_SDL=yes

.include <bsd.port.pre.mk>

.if ${HAVE_SDL:Mmixer}!=""
USE_SDL+=   mixer
.endif

.include <bsd.port.post.mk>

6.18. wxWidgets verwenden

Dieser Abschnitt beschreibt den Status der wxWidgets-Bibliotheken in den Ports und deren Einbindung in das Ports-System.

6.18.1. Einführung

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.

6.18.2. Auswahl der Version

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

Tabelle 24. Variablen, um die wxWidgets-Version festzulegen
Variable	Beschreibung	Standardwert
`USE_WX`	Liste der Versionen, die der Port verwenden kann	Alle verfügbaren Versionen
`USE_WX_NOT`	Liste der Versionen, die der Port nicht verwenden kann	Nichts

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

Tabelle 25. Verfügbare wxWidgets-Versionen
Version	Port
`2.4`	x11-toolkits/wxgtk24
`2.6`	x11-toolkits/wxgtk26
`2.8`	x11-toolkits/wxgtk28

Ab Version 2.5 werden auch Versionen in Unicode unterstützt und über einen Unterport mit dem Suffix -unicode installiert. Dies kann aber auch über Variablen gehandhabt werden (siehe Unicode).

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

Tabelle 26. Spezifikationen der wxWidgets-Versionen
Beschreibung	Beispiel
Einzelne Version	`2.4`
Aufsteigende Versionsnummern	`2.4+`
Absteigende Versionsnummern	`2.6-`
Versionsinterval (muss aufsteigend sein)	`2.4-2.6`

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.

Tabelle 27. Variablen zur Festlegung der bevorzugten wxWidgets-Version
Name	Bestimmt für
`WANT_WX_VER`	den Port
`WITH_WX_VER`	den Benutzer

6.18.3. Komponentenauswahl

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:

Tabelle 28. Verfügbare wxWidgets-Komponenten
Name	Beschreibung	Versionsbeschränkungen
`wx`	Hauptbibliothek	`Nichts`
`contrib`	Beigesteuerte Bibliothek	`Nichts`
`python`	wxPython (Python-Bindungen)	`2.4-2.6`
`mozilla`	wxMozilla	`2.4`
`svg`	wxSVG	`2.6`

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:

Tabelle 29. Verfügbare Typen von wxWidgets-Abhängigkeiten
Name	Beschreibung
`build`	Komponente wird zum Bau benötigt - äquivalent zu `BUILD_DEPENDS`
`run`	Komponente wird zum Ausführen benötigt - äquivalent zu `RUN_DEPENDS`
`lib`	Komponente wird zum Bau und Ausführen benötigt - äquivalent zu `LIB_DEPENDS`

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

Tabelle 30. Standardtypen der wxWidgets-Abhängigkeiten
Komponente	Typ der Abhängigkeit
`wx`	`lib`
`contrib`	`lib`
`python`	`run`
`mozilla`	`lib`
`svg`	`lib`

Beispiel 6. Auswahl von wxWidgets-Komponenten

Der folgende Ausschnitt entspricht einem Port, der die wxWidgets-Version 2.4 und die zugehörigen Bibliotheken verwendet.

USE_WX=       2.4
WX_COMPS=     wx contrib

6.18.4. Unicode

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:

Tabelle 31. Variablen, um Unicode in den wxWidgets-Versionen auszuwählen
Variable	Beschreibung	Bestimmt für
`WX_UNICODE`	Der Port funktioniert ausschließlich mit der Unicode-Version	den Port
`WANT_UNICODE`	Der Port funktioniert in beiden Versionen - bevorzugt wird jedoch Unicode	den Port
`WITH_UNICODE`	Der Port verwendet die Unicode-Version	den Benutzer
`WITHOUT_UNICODE`	Der Port verwendet, falls unterstützt, die normale Version (falls `WX_UNICODE` nicht definiert ist)	den Benutzer

Die Variable WX_UNICODE darf nicht bei Ports benutzt werden, die sowohl die Version mit als auch ohne Unterstützung für Unicode verwenden können. Falls der Port standardmäßig Unterstützung für Unicode bieten soll, verwenden Sie WANT_UNICODE stattdessen.

6.18.5. Feststellen der installierten Version

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.

Beispiel 7. Installierte wxWidgets-Versionen und -Komponenten feststellen

Der folgende Ausschnitt kann in einem Port verwendet werden, der wxWidgets verwendet, falls es installiert ist, oder falls eine Option dafür ausgewählt 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

Der folgende Ausschnitt kann verwendet werden, um die Unterstützung für wxPython zusätzlich zu der von wxWidgets zu aktivieren (beide in Version 2.6), wenn das installiert ist, oder die Option ausgewählt wurde.

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

6.18.6. Vordefinierte Variablen

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

Tabelle 32. Vordefinierte Variablen für Ports, die wxWidgets verwenden
Name	Beschreibung
`WX_CONFIG`	Pfad zum wxWidgets `wx-config`-Skript (mit unterschiedlichem Namen)
`WXRC_CMD`	Pfad zum wxWidgets `wxrc`-Programm (mit unterschiedlichem Namen)
`WX_VERSION`	Version der wxWidgets, die verwendet werden soll (z.B. `2.6`)
`WX_UNICODE`	Falls Unterstützung für Unicode nicht explizit definiert, jedoch verwendet wird, dann wird die Unterstützung automatisch aktiviert.

6.18.7. Verarbeitung in bsd.port.pre.mk

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

Falls WX_PREMK definiert ist, so werden Version, Abhängigkeiten, Komponenten und vordefinierte Variablen nicht geändert, wenn die Variablen des wxWidgets-Ports nach dem Einbinden von bsd.port.pre.mk geändert werden.

Beispiel 8. Verwendung von wxWidgets-Variablen in Kommandos

Der folgende Ausschnitt zeigt die Verwendung von WX_PREMK durch Ausführen des wx-config-Skriptes, um die vollständige Version als Zeichenkette zu erhalten, diese dann einer Variablen zuzuweisen und die Variable anschließend einem Programm zu übergeben.

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

Die wxWidgets-Variablen können problemlos in Kommandos benutzt werden, falls diese in Targets ohne gesetztes WX_PREMK verwendet werden.

6.18.8. Weitere `configure`-Argumente

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.

Tabelle 33. Zulässige Werte für `WX_CONF_ARGS`
Möglicher Wert	Resultierendes Argument
`absolute`	`--with-wx-config=${WX_CONFIG}`
`relative`	`--with-wx=${LOCALBASE} --with-wx-config=${WX_CONFIG:T}`

6.19. Verwendung von Lua

Dieser Abschnitt beschreibt den Status der Lua-Bibliotheken in den Ports und deren Einbindung in das Ports System.

6.19.1. Einführung

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.

6.19.2. Auswahl der Version

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

Tabelle 34. Variablen, um die Lua-Version festzulegen
Variable	Beschreibung	Standardwert
`USE_LUA`	Liste der Versionen, welche der Port verwenden kann	Alle verfügbaren Versionen
`USE_LUA_NOT`	Liste der Versionen, die der Port nicht verwenden kann	Nichts

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

Tabelle 35. Verfügbare Lua-Versionen
Version	Port
`4.0`	lang/lua4
`5.0`	lang/lua50
`5.1`	lang/lua

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

Tabelle 36. Spezifikationen der Lua-Versionen
Beschreibung	Beispiel
Spezielle Version	`4.0`
Aufsteigende Versionen	`5.0+`
Absteigende Versionen	`5.0-`
Versionenintervall (muss aufsteigend sein)	`5.0-5.1`

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.

Tabelle 37. Variablen zur Festlegung der bevorzugten Lua-Version
Name	Bestimmt für
`WANT_LUA_VER`	den Port
`WITH_LUA_VER`	den Benutzer

Beispiel 9. Auswahl der Lua-Version

Der folgende Ausschnitt entspricht einem Port, der Lua in den Versionen 5.0 oder 5.1 verwenden kann und standardmäßig 5.0 verwendet. Diese Einstellung kann durch die benutzerdefinierte Variable WITH_LUA_VER überschrieben werden.

USE_LUA=      5.0-5.1
WANT_LUA_VER= 5.0

6.19.3. Komponentenauswahl

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:

Tabelle 38. Verfügbare Lua-Komponenten
Name	Beschreibung	Versionseinschränkungen
`lua`	Hauptbibliothek	Keine
`tolua`	Bibliothek für die Unterstützung von C/C++-Code	`4.0-5.0`
`ruby`	Ruby-Bindungen	`4.0-5.0`

Es gibt weitere Komponenten, die jedoch Module für den Interpreter sind und nicht von Anwendungen benutzt werden (nur von anderen Modulen).

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:

Tabelle 39. Verfügbare Typen von Lua-Abhängigkeiten
Name	Beschreibung
`build`	Komponente wird zum Bau benötigt - äquivalent zu `BUILD_DEPENDS`
`run`	Komponente wird zum Ausführen benötigt - äquivalent zu `RUN_DEPENDS`
`lib`	Komponente wird zum Bau und zum Ausführen benötigt - äquivalent zu `LIB_DEPENDS`

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

Tabelle 40. Standardtypen für Lua-Abhängigkeiten
Komponente	Typ der Abhängigkeit
`lua`	`lib` für `4.0-5.0` (shared) und `build` für `5.1` (static)
`tolua`	`build` (static)
`ruby`	`lib` (shared)

Beispiel 10. Auswahl von Lua-Komponenten

Der folgende Ausschnitt entspricht einem Port, welcher die Lua-Version 4.0 und die zugehörigen Ruby-Bindungen verwendet.

USE_LUA=      4.0
LUA_COMPS=    lua ruby

6.19.4. Feststellen der installierten Version

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.

Beispiel 11. Installierte Lua-Versionen und- Komponenten feststellen

Der folgende Ausschnitt kann in einem Port verwendet werden, der Lua benutzt, falls es installiert ist oder eine Option dafür ausgewählt 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

Der folgende Ausschnitt kann verwendet werden, um die Unterstützung für tolua zusätzlich zu der von Lua zu aktivieren (beide in Version 4.0), wenn dies installiert ist oder die Option ausgewählt wurde.

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

6.19.5. Vordefinierte Variablen

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

Tabelle 41. Vordefinierte Variablen für Ports, die Lua verwenden
Name	Beschreibung
`LUA_VER`	Die Lua-Version, die verwendet wird (z.B. `5.1`)
`LUA_VER_SH`	Die Hauptversion für shared-Lua-Bibliotheken (z.B. `1`)
`LUA_VER_STR`	Die Lua-Version ohne die Punkte (z.B. `51`)
`LUA_PREFIX`	Der Präfix, unter dem Lua (und Komponenten) installiert ist
`LUA_SUBDIR`	Das Verzeichnis unter ${PREFIX}/bin, ${PREFIX}/share und ${PREFIX}/lib, in welchem Lua installiert ist
`LUA_INCDIR`	Das Verzeichnis, in dem Lua- und tolua-Header-Dateien installiert sind
`LUA_LIBDIR`	Das Verzeichnis, in dem Lua- und tolua-Bibliotheken installiert sind
`LUA_MODLIBDIR`	Das Verzeichnis, in dem Lua Modul-Bibliotheken (.so) installiert sind
`LUA_MODSHAREDIR`	Das Verzeichnis, in dem Lua-Module (.lua) installiert sind
`LUA_PKGNAMEPREFIX`	Der Paketnamen-Präfix, der von Lua-Modulen verwendet wird
`LUA_CMD`	Das Verzeichnis, in dem der Lua-Interpreter liegt
`LUAC_CMD`	Das Verzeichnis, in dem der Lua-Compiler liegt
`TOLUA_CMD`	Das Verzeichnis, in dem das tolua-Programm liegt

Beispiel 12. Einem Port mitteilen, in welchem Verzeichnis Lua liegt

Der folgende Ausschnitt zeigt, wie einem Port, welcher ein configure-Skript verwendet, mitgeteilt werden kann, wo die Lua-Header-Dateien und Bibliotheken liegen.

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

6.19.6. Verarbeitung in bsd.port.pre.mk

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

Falls LUA_PREMK definiert ist, so werden Version, Abhängigkeiten, Komponenten und vordefinierte Variablen nicht geändert, wenn die Variablen des Lua-Ports nach dem Einbinden von bsd.port.pre.mk geändert werden.

Beispiel 13. Verwendung von Lua-Variablen in Kommandos

Der folgende Ausschnitt zeigt die Verwendung von LUA_PREMK durch Ausführen des Lua-Interpreters, um die vollständige Version als Zeichenkette zu erhalten, diese dann einer Variablen zuzuweisen und die Variable schließlich einem Programm zu übergeben.

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

Die Lua-Variablen können problemlos in Befehlen benutzt werden, falls diese in Targets ohne gesetztes LUA_PREMK verwendet werden.

6.20. Xfce verwenden

Die USE_XFCE-Variable wird für die automatische Konfiguration der Abhängigkeiten eingesetzt, welche die Xfce-Basisbibliotheken oder Anwendungen wie x11-toolkits/libxfce4gui und x11-wm/xfce4-panel verwenden.

Die folgenden Xfce-Bibliotheken und -Anwendungen werden derzeit unterstützt:

Die folgenden zusätzlichen Parameter werden unterstützt:

configenv: Benutzen Sie dies, wenn Ihr Port eine speziell angepasste CONFIGURE_ENV-Variable benötigt, um seine erforderlichen Bibliotheken zu finden.
```
-I${LOCALBASE}/include
	    -L${LOCALBASE}/lib
```

wird CPPFLAGS hinzugefügt und ergibt CONFIGURE_ENV.

Wenn also ein Port von sysutils/xfce4-mcs-manager abhängt und die speziellen CPPFLAGS in seiner configure-Umgebung verlangt, dann würde die Syntax wie folgt aussehen:

USE_XFCE=        mcsmanager configenv

6.21. Mozilla verwenden

Tabelle 42. Variablen für Ports, die Mozilla verwenden
`USE_GECKO`	Vom Port unterstützte Gecko-Backends. Mögliche Werte sind: `libxul` (libxul.so), `seamonkey` (libgtkembedmoz.so, (veraltet, sollte daher nicht mehr verwendet werden).
`USE_FIREFOX`	Der Port benötigt Firefox, um korrekt zu funktionieren. Mögliche Werte sind: `yes` (verwendet die Standardversion), `40`, `36`, `35`. Die Standardversion ist derzeit `40`.
`USE_FIREFOX_BUILD`	Um den Port zu bauen, muss Firefox installiert sein. Wird diese Variable gesetzt, wird automatisch auch `USE_FIREFOX` gesetzt.
`USE_SEAMONKEY`	Der Port benötigt Seamonkey, um korrekt zu funktionieren. Mögliche Werte sind: `yes` (verwendet die Standardversion), `20`, `11` (veraltet, sollte daher nicht mehr verwendet werden). Die Standardversion ist `20`.
`USE_SEAMONKEY_BUILD`	Um den Port zu bauen, muss Seamonkey installiert sein. Wird diese Variable gesetzt, wird automatisch auch `USE_SEAMONKEY` gesetzt.
`USE_THUNDERBIRD`	Dieser Port benötigt Thunderbird, um korrekt zu funktionieren. Mögliche Werte sind: `yes` (verwendet die Standardversion), `31`, `30` (veraltet, sollte daher nicht mehr verwendet werden). Die Standardversion ist `31`.
`USE_THUNDERBIRD_BUILD`	Um den Port zu bauen, muss Thunderbird installiert sein. Wird diese Variable gesetzt, wird automatisch auch `USE_THUNDERBIRD` gesetzt.

Eine komplette Liste aller verfügbaren Variablen finden Sie in der Datei /usr/ports/Mk/bsd.gecko.mk.

6.22. Benutzung von Datenbanken

Tabelle 43. Variablen für Ports, die Datenbanken benutzen
Variable	Bedeutung
`USE_BDB`	Falls die Variable auf `yes` gesetzt ist, füge eine Abhängigkeit von databases/db41 hinzu. Die Variable kann auch folgende Werte annehmen: 40, 41, 42, 43, 44, 46, 47, 48 oder 51. Sie können eine Folge akzeptierter Werte angeben - `USE_BDB`=42+ stellt die höchste installierte Version fest und greift auf 42 zurück, falls sonst nichts installiert ist.
`USE_MYSQL`	Falls die Variable auf `yes` gesetzt ist, füge databases/mysql55-server als Abhängigkeit hinzu. Die damit verknüpfte Variable `WANT_MYSQL_VER` kann Werte wie 323, 40, 41, 50, 51, 52, 55, oder 60 annehmen.
`USE_PGSQL`	Falls die Variable auf `yes` gesetzt ist, füge eine Abhängigkeit von databases/postgresql84 hinzu. Die damit verknüpfte Variable `WANT_PGSQL_VER` kann Werte wie 73, 74, 80, 81, 82, 83, oder 90 annehmen.

Weitere Informationen zu diesem Thema finden sich in der Datei bsd.database.mk.

6.23. Starten und Anhalten von Diensten (rc Skripten)

rc.d-Skripten werden zum Starten von Diensten während des Systemstarts verwendet und um den Administratoren einen Standardweg zum Anhalten und Starten von Diensten zu bieten. Ports halten sich an dieses systemweite rc.d-Framework. Details zu deren Benutzung können im rc.d Kapitel des Handbuchs nachgelesen werden. Ausführliche Beschreibungen der verfügbaren Befehle stehen in rc(8) und rc.subr(8). Desweiteren gibt es einen Artikel zu praktischen Aspekten bezüglich rc.d-Skripten.

Ein oder mehrere rc.d-Skripten können installiert werden mittels:

USE_RC_SUBR=    doormand

Skripten müssen im Unterverzeichnis files abgelegt und jeder Skript-Datei muss ein .in-Suffix hinzugefügt werden. Standardmäßige SUB_LIST-Ersetzungen werden für diese Dateien unterstützt. Die Verwendung von %%PREFIX%% und %%LOCALBASE%% wird dringend empfohlen. Näheres zu SUB_LIST kann im zugehörigen Kapitel nachgelesen werden.

Für FreeBSD-Versionen, die älter als 6.1-RELEASE sind, ist die Integration mittels rcorder(8) möglich, indem USE_RCORDER anstatt USE_RC_SUBR verwendet wird. Die Verwendung dieser Methode ist jedoch nur notwendig, wenn der Port in die Verzeichnisstruktur des Basissystems installiert werden kann oder der Dienst vor den FILESYSTEMS-Skripten in rc.d des Basissystems gestartet sein muss.

Seit FreeBSD 6.1-RELEASE sind lokale rc.d-Skripten (inklusive der durch Ports installierten) im allgemeinen rcorder(8) des Basissystems.

Beispiel eines einfachen rc.d-Skripts:

#!/bin/sh

# $FreeBSD$
#
# PROVIDE: doormand
# REQUIRE: LOGIN
# KEYWORD: shutdown
#
# Add the following lines to /etc/rc.conf.local or /etc/rc.conf
# to enable this service:
#
# doormand_enable (bool):    Set to NO by default.
#                Set it to YES to enable doormand.
# doormand_config (path):    Set to %%PREFIX%%/etc/doormand/doormand.cf
#                by default.
#

. /etc/rc.subr

name="doormand"
rcvar=${name}_enable

command=%%PREFIX%%/sbin/${name}
pidfile=/var/run/${name}.pid

load_rc_config $name

: ${doormand_enable="NO"}
: ${doormand_config="%%PREFIX%%/etc/doormand/doormand.cf"}

command_args="-p $pidfile -f $doormand_config"

run_rc_command "$1"

Solange kein guter Grund dafür besteht, einen Dienst früher starten zu lassen, sollten alle Ports-Skripten

REQUIRE: LOGIN

verwenden. Falls der Port von einem bestimmten Benutzer (außer root) ausgeführt wird, ist dies zwingend.

KEYWORD: shutdown

ist im Skript oben deswegen vorhanden, weil der frei erfundene Beispiel-Port einen Dienst startet und dieser beim Herunterfahren des Systems sauber beendet werden sollte. Startete das Skript keinen persistenten Dienst, wäre dies nicht notwendig.

Für die Wertzuweisung von Variablen sollte "=" anstatt ":=" verwendet werden, da bei Ersterem nur auf einen Standardwert gesetzt wird, wenn die Variable vorher noch nicht gesetzt war, und bei Letzterem dieser gesetzt wird, auch wenn der Wert vorher Null gewesen ist. Ein Benutzer kann durchaus einen Ausdruck wie

doormand_flags=""

in seiner rc.conf.local-Datei stehen haben, und eine Variablenzuweisung mittels ":=" würde in diesem Fall die Benutzerdefinition überschreiben.

Es sollten keine weiteren Skripten mit der .sh-Endung hinzugefügt werden. Irgendwann wird es ein Massenumbenennen aller Skripten im Repository geben, die immer noch diese Endung haben.

6.23.1. Anhalten und Deinstallieren von Diensten

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.

6.24. Hinzufügen von Benutzern und Gruppen

Manche Ports setzen voraus, dass ein bestimmter Benutzer auf dem System angelegt ist. Wählen Sie in einem solchen Fall eine freie Kennnummer zwischen 50 und 999 aus und tragen Sie diese in ports/UIDs (für Benutzer) oder ports/GIDs (für Gruppen) ein. Stellen Sie dabei sicher, dass Sie keine Kennnummer auswählen, die bereits vom System oder von anderen Ports verwendet wird.

Erstellen Sie bitte eine entsprechende Patch-Datei für diese beiden Dateien, wenn für Ihren Port ein neuer Benutzer oder eine neue Gruppe angelegt werden muss.

Sie können dann die Variablen USERS und GROUPS im Makefile benutzen, um bei der Port-Installation das automatische Anlegen des Benutzers zu veranlassen.

USERS=  pulse
GROUPS= pulse pulse-access pulse-rt

Die Liste mit den momentan belegten UIDs (GIDs) befindet sich in ports/UIDs (ports/GIDs).

6.25. Von Kernelquellen abhängige Ports

Einige Ports (beispielsweise vom Kernel ladbare Module) benötigen die Kernelsourcen, damit sie gebaut werden können. Die folgenden Zeilen beschreiben den korrekten Weg, wie Sie feststellen können, ob der Benutzer die Kernelsourcen installiert hat:

.if !exists(${SRC_BASE}/sys/Makefile)

IGNORE=         requires kernel sources to be installed
.endif

Last modified on: 9. März 2024 by Danilo G. Baio

Home