path: root/documentation/content/de/books/porters-handbook/special/_index.adoc

---
title: Kapitel 6. Besonderheiten
prev: books/porters-handbook/makefile
next: books/porters-handbook/plist
showBookMenu: true
weight: 6
path: "/books/porters-handbook/special/"
---

[[special]]
= Besonderheiten
:doctype: book
:toc: macro
:toclevels: 1
:icons: font
:sectnums:
:sectnumlevels: 6
:sectnumoffset: 6
:partnums:
:source-highlighter: rouge
:experimental:
:images-path: books/porters-handbook/

ifdef::env-beastie[]
ifdef::backend-html5[]
:imagesdir: ../../../../images/{images-path}
endif::[]
ifndef::book[]
include::shared/authors.adoc[]
include::shared/mirrors.adoc[]
include::shared/releases.adoc[]
include::shared/attributes/attributes-{{% lang %}}.adoc[]
include::shared/{{% lang %}}/teams.adoc[]
include::shared/{{% lang %}}/mailing-lists.adoc[]
include::shared/{{% lang %}}/urls.adoc[]
toc::[]
endif::[]
ifdef::backend-pdf,backend-epub3[]
include::../../../../../shared/asciidoctor.adoc[]
endif::[]
endif::[]

ifndef::env-beastie[]
toc::[]
include::../../../../../shared/asciidoctor.adoc[]
endif::[]

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

[[porting-shlibs]]
== Shared-Libraries

Wenn Ihr Port eine oder mehrere Shared-Libraries installiert, dann definieren Sie bitte eine `USE_LDCONFIG` make-Variable, die [.filename]#bsd.port.mk# anweisen wird, `${LDCONFIG} -m` auf das Verzeichnis, in das die neue Library installiert wird (normalerweise [.filename]#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 [.filename]#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.

[.programlisting]
....
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 [.filename]#PREFIX/lib/foo# und [.filename]#PREFIX/lib/bar# installiert, könnten Sie folgendes in Ihrem [.filename]#Makefile# benutzen:

[.programlisting]
....
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. package: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 package:www/seamonkey[] tut.

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

Versuchen Sie Shared-Library-Versionsnummern im [.filename]#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.

[[porting-restrictions]]
== 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.

[IMPORTANT]
====
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.

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

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

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

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

=== `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 [.filename]#/usr/ports/LEGAL# hinzufügen sollte, der genau beschreibt, was die Beschränkung mit sich bringt.

[[building]]
== Build-Mechanismen

[[parallel-builds]]
=== 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 man: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 [.filename]#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 [.filename]#/etc/make.conf# erzwingt.

[[using-make]]
=== `make`, `gmake` und `imake`

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

.Port-Variablen im Zusammenhang mit gmake
[cols="1,1", frame="none", options="header"]
|===
| 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 [.filename]#Makefile#-Dateien aus [.filename]#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 [.filename]#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`.

[[using-configure]]
=== `configure` Skript

Wenn Ihr Port ein `configure`-Skript benutzt, um [.filename]#Makefile#-Dateien aus [.filename]#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.

.Variablen für Ports, die `configure` benutzen
[cols="1,1", frame="none", options="header"]
|===
| 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}`.
|===

[[using-scons]]
=== Benutzung von `scons`

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

.Variablen für Ports, die `scons` benutzen
[cols="1,1", frame="none", options="header"]
|===
| 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 [.filename]#SConstruct# im Quelltext alles, was SCons in `SCONS_ENV` übergeben wird, respektieren zu lassen (das ist hauptsächlich `CC/CXX/CFLAGS/CXXFLAGS`), patchen Sie [.filename]#SConstruct#, sodass das Build `Environment` wie folgt konstruiert wird:

[.programlisting]
....
env = Environment(**ARGUMENTS)
....

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

[[using-autotools]]
== Benutzung von GNU autotools

[[using-autotools-introduction]]
=== 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:

[.programlisting]
....
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.

[[using-libtool]]
=== `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:

[.programlisting]
....
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 [.filename]#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 [.filename]#bsd.autotools.mk#.

[[using-libltdl]]
=== `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.

[.programlisting]
....
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.

[[using-autoconf]]
=== `autoconf` und `autoheader`

Manche Ports enthalten kein Konfigurationsskript, sondern eine autoconf-Vorlage in der [.filename]#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.

[.programlisting]
....
USE_AUTOTOOLS=    autoconf:version[:env]
....

und

[.programlisting]
....
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 [.filename]#Makefile# des Ports ausser Kraft gesetzt werden, wenn erforderlich. Wie bei den `libtool`-Äquivalenten werden die meisten Ports dies aber nicht benötigen.

[[using-automake]]
=== `automake` und `aclocal`

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

Ähnliches gilt für Pakete, die gelegentlich keine [.filename]#aclocal.m4#-Dateien mitliefern, welche ebenfalls zum Erstellen der Software benötigt werden. Diese können durch `aclocal` erzeugt werden, welches [.filename]#configure.ac# oder [.filename]#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:

[.programlisting]
....
USE_AUTOTOOLS=    automake:version[:env]
....

und

[.programlisting]
....
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 [.filename]#Makefile# des Ports, falls nötig, außer Kraft gesetzt werden kann.

[[using-gettext]]
== Benutzung von GNU `gettext`

=== Grundlegende Benutzung

Wenn Ihr Port `gettext` benötigt, setzen Sie einfach `USE_GETTEXT` auf `yes`, und Ihr Port bekommt die Abhängigkeit von package: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 package: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:

[.programlisting]
....
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:

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

=== 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 <<knobs-without-nls,`WITHOUT_NLS`>> benutzen. Für Ports mit niedriger bis mittlerer Komplexität können Sie sich auf das folgende Idiom verlassen:

[.programlisting]
....
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 [.filename]#Makefile#-Teil dieser Aufgabe ist schon durch obiges Idiom erledigt. Das wird im Abschnitt über <<plist-sub,Fortgeschrittene [.filename]#pkg-plist#-Methoden>> erklärt. Kurz gesagt, jedes Vorkommen von `%%NLS%%` in [.filename]#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 [.filename]#pkg-plist# einzufügen. Zum Beispiel:

[.programlisting]
....
%%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. <<plist-dynamic,Dynamische Packlistenerzeugung>>.

=== Behandlung von Message-Catalog-Verzeichnissen

Bei der Installation von Message-Catalog-Dateien gibt es einen Punkt zu beachten. Ihr Zielverzeichnis, das unter [.filename]#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 [.filename]#/etc/mtree/BSD.local.dist# aufgelistet; das heisst, sie sind Teil des Systems. Die Verzeichnisse für viele andere Sprachen sind Teil des Ports package:devel/gettext[]. Sie wollen vielleicht dessen [.filename]#pkg-plist# zur Hand nehmen, um festzustellen, ob Ihr Port eine Message-Catalog-Datei für eine seltene Sprache installiert.

[[using-perl]]
== 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 http://cpan.org/modules/by-module/[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.

.Variablen für Ports, die `perl` benutzen
[cols="1,1", frame="none", options="header"]
|===
| 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`.
|===

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

[[using-x11]]
== Benutzung von X11

[[x11-variables]]
=== 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 [.filename]#/usr/ports/Mk/bsd.xorg.mk#.

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

[[use-xorg-example]]
.Beispiel für USE_XORG
[example]
====
[.programlisting]
....
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.

.Variablen für Ports, die X benutzen
[cols="1,1", frame="none"]
|===
|`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`.
|===

.Variablen bei Abhängigkeit von einzelnen Teilen von X11
[cols="1,1", frame="none"]
|===
|`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(R)-Schriftarten bereitstellt.

|`X_FONTS_TYPE1_PORT`
|Ein Port, der Type1-Schriftarten bereitstellt.

|`X_MANUALS_PORT`
|Ein Port, der entwicklerorientierte Manualpages bereitstellt.
|===

[[using-x11-vars]]
.Benutzung von X11-bezogenen Variablen in einem Port
[example]
====
[.programlisting]
....
# 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
....

====

[[x11-motif]]
=== Ports, die Motif benötigen

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

Die Variable `MOTIFLIB` wird von [.filename]#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 [.filename]#Makefile# oder [.filename]#Imakefile# referenziert wird.

Es gibt zwei verbreitete Fälle:

* Wenn sich der Port in seinem [.filename]#Makefile# oder [.filename]#Imakefile# auf die Motif-Bibliothek als `-lXm` bezieht, ersetzen Sie das einfach durch `${MOTIFLIB}`.
* Wenn der Port in seinem [.filename]#Imakefile#`XmClientLibs` 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.

=== X11 Schriftarten

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

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

[.programlisting]
....
USE_DISPLAY=  yes
....

[[desktop-entries]]
=== Desktop-Einträge

Desktop-Einträge (http://standards.freedesktop.org/desktop-entry-spec/latest/[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 [.filename]#.desktop#-Datei wird dann automatisch erzeugt, installiert und der [.filename]#pkg-plist# hinzugefügt. Die Syntax ist:

[.programlisting]
....
DESKTOP_ENTRIES=  "NAME" "COMMENT" "ICON" "COMMAND" "CATEGORY" StartupNotify
....

Die Liste der möglichen Kategorien ist auf der http://standards.freedesktop.org/menu-spec/latest/apa.html[Freedesktop Webseite] abrufbar. `StartupNotify` zeigt an, ob die Applikation den Status in Umgebungen, die Startup-Notifications kennen, löschen wird.

Beispiel:

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

[[using-gnome]]
== Benutzung von GNOME

Das FreeBSD/GNOME-Projekt benutzt seine eigene Gruppe von Variablen, um zu definieren, welche GNOME-Komponenten ein bestimmter Port benutzt. Eine http://www.FreeBSD.org/gnome/docs/porting/[ umfassende Liste dieser Variablen] existiert innerhalb der Webseite des FreeBSD/GNOME-Projektes.

[[using-qt]]
== Benutzung von Qt

[[qt-common]]
=== Ports, die Qt benötigen

.Variablen für Ports, die Qt benötigen
[cols="1,1", frame="none"]
|===
|`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.
|===

.Zusätzliche Variablen für Ports, die Qt 4.xi benutzen
[cols="1,1", frame="none"]
|===
|`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:

[.programlisting]
....
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:

[.programlisting]
....
CONFIGURE_ENV+= UIC="${UIC}" QMAKE="${QMAKE}" QMAKESPEC="${QMAKESPEC}"
MAKE_ENV+=      QMAKESPEC="${QMAKESPEC}"
....

[[qt4-components]]
=== 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 [.filename]#/usr/ports/Mk/bsd.qt.mk# aufgelistet):

.Verfügbare Qt4-Bibliothekskomponenten
[cols="1,1", frame="none", options="header"]
|===
| 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.

.Verfügbare Qt4-Tool-Komponenten
[cols="1,1", frame="none", options="header"]
|===
| 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 [.filename]#*.rc# oder [.filename]#*.qrc# Dateien enthält)

|`uic`
|User-Interface-Compiler (wird benötigt, falls die Applikation von Qt-Designer erzeugte [.filename]#*.ui# Dateien enthält - gilt für praktisch jede Qt-Applikation mit einer GUI)
|===

.Verfügbare Qt4-Plugin-Komponenten
[cols="1,1", frame="none", options="header"]
|===
| 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)
|===

[[qt4-components-example]]
.Qt4-Komponenten auswählen
[example]
====
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`:

[.programlisting]
....
USE_QT_VER=    4
QT_COMPONENTS= gui moc_build qmake_build rcc_build uic_build
....

====

[[qt-additional]]
=== Zusätzliche Besonderheiten

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

[.programlisting]
....
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 [.filename]#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.:
+
[.programlisting]
....
${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. package:editors/texmaker[] ist hierfür ein Beispiel- siehe [.filename]#patch-texmaker.pro# im [.filename]#files#-Verzeichnis dieses Ports als eine Vorlage, die zeigt, wie man dies direkt in der Qmake Projektdatei löst.

[[using-kde]]
== Benutzung von KDE

[[kde-variables]]
=== Variablen-Definitionen (KDE 3)

.Variablen für Ports, die KDE 3 benutzen
[cols="1,1", frame="none"]
|===
|`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`.
|===

[[kde4-variables]]
=== 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 [.filename]#/usr/ports/Mk/bsd.kde4.mk# enthält stets die aktuelle Liste):

.Verfügbare KDE 4-Komponenten
[cols="1,1", frame="none", options="header"]
|===
| 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 [.filename]#/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 [.filename]#/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.

[[kde4-components-example]]
.`USE_KDE4`-Beispiel
[example]
====
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.

[.programlisting]
....
USE_CMAKE=     yes
USE_KDE4=      automoc4 kdelibs kdeprefix
USE_QT_VER=    4
QT_COMPONENTS= qmake_build moc_build rcc_build uic_build
....

====

[[using-java]]
== Benutzung von Java

[[java-variables]]
=== Variablen-Definitionen

Wenn Ihr Port ein Java(TM) Development Kit (JDK(TM)) 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 package:java/jdk16[].

.Variablen, die von Ports, die Java benutzen, gesetzt werden müssen
[cols="1,1", frame="none", options="header"]
|===
| 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:

.Bereitgestellte Variablen für Ports, die Java benutzen
[cols="1,1", frame="none", options="header"]
|===
| 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. [.filename]#'/usr/local/diablo-jdk1.6.0'#).

|`JAVAC`
|Pfad zum Java-Compiler, der benutzt werden soll (z.B. [.filename]#'/usr/local/diablo-jdk1.6.0/bin/javac'#.

|`JAR`
|Pfad zum `jar`-Werkzeug, das benutzt werden soll (z.B.'[.filename]#'/usr/local/diablo-jdk1.6.0/bin/jar# oder [.filename]#'/usr/local/bin/fastjar'#).

|`APPLETVIEWER`
|Pfad zum `appletviewer`-Werkzeug (z.B. [.filename]#'/usr/local/diablo-jdk1.6.0/bin/appletviewer'#).

|`JAVA`
|Pfad zur `java` Binärdatei. Benutzen Sie dies, um Java-Programme auszuführen (z.B.[.filename]#'/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, [.filename]#${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:

.Konstanten, die für Ports, welche Java benutzen, definiert sind
[cols="1,1", frame="none", options="header"]
|===
| Konstante
| Wert

|`JAVASHAREDIR`
|Das Basis-Verzeichnis für alles, was mit Java zusammenhängt. Standardmäßig [.filename]#${PREFIX}/shared/java#.

|`JAVAJARDIR`
|Das Verzeichnis, wohin JAR-Dateien installiert werden sollen. Standardmäßig [.filename]#${JAVASHAREDIR}/classes#.

|`JAVALIBDIR`
|Das Verzeichnis, in dem JAR-Dateien, die von anderen Ports installiert wurden, liegen. Standardmäßig [.filename]#${LOCALBASE}/shared/java/classes#.
|===

Die entsprechenden Einträge sind sowohl in `PLIST_SUB` (dokumentiert in crossref:plist[plist-sub,Änderungen an pkg-plist mit Hilfe von make-Variablen]) als auch in `SUB_LIST` definiert.

[[java-building-with-ant]]
=== 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 <<building>> dokumentiert ist.

[[java-best-practices]]
=== Optimales Verfahren

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

[.programlisting]
....
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 [.filename]#${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 [.filename]#${JAVAJARDIR}#) benutzen soll.

Unabhängig von der Art Ihres Ports (Bibliothek oder Applikation), sollte die zusätzliche Dokumentation an die <<install-documentation,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 ([.filename]#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 [.filename]#pkg-plist# befürwortet die Benutzung von `PORTDOCS`.

Der Vorgabewert für `DATADIR` ist [.filename]#${PREFIX}/shared/${PORTNAME}#. Es ist eine gute Idee, `DATADIR` für Java-Ports stattdessen auf [.filename]#${JAVASHAREDIR}/${PORTNAME}# zu setzen. In der Tat wird `DATADIR` automatisch zu `PLIST_SUB` (dokumentiert in crossref:plist[plist-sub,Änderungen an pkg-plist mit Hilfe von make-Variablen]) hinzugefügt, d.h. Sie können `%%DATADIR%%` direkt in [.filename]#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 http://www.freebsd.org/java/[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 [.filename]#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 http://www.freebsd.org/cgi/cvsweb.cgi/ports/Mk/bsd.java.mk[ 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 [.filename]#bsd.java.mk#.

Gleichermaßen gibt es eine definierte Richtlinie für die `CATEGORIES` eines Java-Ports, die in crossref:flavors[makefile-categories, Kategorisierung] erklärt wird.

[[using-php]]
== Webanwendungen, Apache und PHP

[[using-apache]]
=== Apache

.Variablen für Ports, die Apache verwenden
[cols="1,1", frame="none"]
|===
|`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 [.filename]#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.
|===

.Nützliche Variablen für Ports von Apache-Modulen
[cols="1,1", frame="none"]
|===
|`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 [.filename]#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`.
|===

[[web-apps]]
=== Webanwendungen

Webanwendungen sollten nach [.filename]#PREFIX/www/programmname# installiert werden. Der Einfachheit halber ist dieser Pfad sowohl im [.filename]#Makefile# als auch in [.filename]#pkg-plist# als `WWWDIR` verfügbar. Der relative Pfad `PREFIX` ist hingegen im [.filename]#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.

[[php-variables]]
=== PHP

.Variablen für Ports, die PHP verwenden
[cols="1,1", frame="none"]
|===
|`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.
|===

=== 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 [.filename]#pkg-plist# hinzugefügt.

Die Datei [.filename]#${PORTSDIR}/devel/pear/bsd.pear.mk# muss am Ende des [.filename]##Makefile##s eingebunden werden.

[[pear-makefile]]
.Beispiel eines Makefiles für eine PEAR Klasse
[example]
====
[.programlisting]
....
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>
....

====

[[using-python]]
== 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.

[.programlisting]
....
PKGNAMEPREFIX= ${PYTHON_PKGNAMEPREFIX}
....

.Nützliche Variablen für Ports, die Python verwenden
[cols="1,1", frame="none"]
|===
|`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 [.filename]#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 [.filename]#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 [.filename]#/usr/ports/Mk/bsd.python.mk# zu finden.

[[using-tcl]]
== 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.

.Äußerst nützliche Variablen für Ports, die Tcl/Tk benutzen
[cols="1,1", frame="none"]
|===
|`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 [.filename]#/usr/ports/Mk/bsd.tcl.mk#.

[[using-emacs]]
== Emacs benutzen

Dieser Abschnitt muss noch geschrieben werden.

[[using-ruby]]
== Ruby benutzen

.Nützliche Variablen für Ports, die Ruby verwenden
[cols="1,1", frame="none", options="header"]
|===
| Variable
| Description

|`USE_RUBY`
|Der Port benötigt Ruby.

|`USE_RUBY_EXTCONF`
|Der Port verwendet [.filename]#extconf.rb# für die Konfiguration.

|`USE_RUBY_SETUP`
|Der Port verwendet [.filename]#setup.rb# für die Konfiguration.

|`RUBY_SETUP`
|Legt den alternativen Namen von [.filename]#setup.rb# fest. Üblich ist der Wert [.filename]#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 [.filename]#pkg-plist# so häufig wie möglich verwendet und in einem Port nicht neu definiert werden.

.Ausgewählte read-only-Variablen für Ports, die Ruby verwenden
[cols="1,1,1", frame="none", options="header"]
|===
| 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 [.filename]#/usr/ports/Mk/bsd.ruby.mk# eingesehen werden.

[[using-sdl]]
== 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 package:devel/sdl12[] und package:x11-toolkits/sdl_gui[] verwenden.

Die folgenden SDL-Bibliotheken sind derzeit bekannt:

* sdl: package:devel/sdl12[]
* gfx: package:graphics/sdl_gfx[]
* gui: package:x11-toolkits/sdl_gui[]
* image: package:graphics/sdl_image[]
* ldbad: package:devel/sdl_ldbad[]
* mixer: package:audio/sdl_mixer[]
* mm: package:devel/sdlmm[]
* net: package:net/sdl_net[]
* sound: package:audio/sdl_sound[]
* ttf: package:graphics/sdl_ttf[]

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

[.programlisting]
....
USE_SDL=        net mixer
....

Die Abhängigkeit von package:devel/sdl12[], die durch package:net/sdl_net[] und package: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:

[.programlisting]
....
WANT_SDL=yes

.include <bsd.port.pre.mk>

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

.include <bsd.port.post.mk>
....

[[using-wx]]
== wxWidgets verwenden

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

[[wx-introduction]]
=== 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.

[[wx-version]]
=== 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):

[[wx-ver-sel-table]]
.Variablen, um die wxWidgets-Version festzulegen
[cols="1,1,1", frame="none", options="header"]
|===
| 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:

.Verfügbare wxWidgets-Versionen
[cols="1,1", frame="none", options="header"]
|===
| Version
| Port

|`2.4`
|package:x11-toolkits/wxgtk24[]

|`2.6`
|package:x11-toolkits/wxgtk26[]

|`2.8`
|package:x11-toolkits/wxgtk28[]
|===

[NOTE]
====
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 <<wx-unicode>>).
====

Die Variablen in <<wx-ver-sel-table>> können auf einen oder mehrere (durch Leerzeichen getrennt) der folgenden Werte gesetzt werden:

.Spezifikationen der wxWidgets-Versionen
[cols="1,1", frame="none", options="header"]
|===
| 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.

.Variablen zur Festlegung der bevorzugten wxWidgets-Version
[cols="1,1", frame="none", options="header"]
|===
| Name
| Bestimmt für

|`WANT_WX_VER`
|den Port

|`WITH_WX_VER`
|den Benutzer
|===

[[wx-components]]
=== 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:

.Verfügbare wxWidgets-Komponenten
[cols="1,1,1", frame="none", options="header"]
|===
| 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 <<wx-def-dep-types>>). Die folgenden Typen sind verfügbar:

.Verfügbare Typen von wxWidgets-Abhängigkeiten
[cols="1,1", frame="none", options="header"]
|===
| 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:

[[wx-def-dep-types]]
.Standardtypen der wxWidgets-Abhängigkeiten
[cols="1,1", frame="none", options="header"]
|===
| Komponente
| Typ der Abhängigkeit

|`wx`
|`lib`

|`contrib`
|`lib`

|`python`
|`run`

|`mozilla`
|`lib`

|`svg`
|`lib`
|===

[[wx-components-example]]
.Auswahl von wxWidgets-Komponenten
[example]
====
Der folgende Ausschnitt entspricht einem Port, der die wxWidgets-Version `2.4` und die zugehörigen Bibliotheken verwendet.

[.programlisting]
....
USE_WX=       2.4
WX_COMPS=     wx contrib
....

====

[[wx-unicode]]
=== 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:
[[wx-unicode-var-table]]
.Variablen, um Unicode in den wxWidgets-Versionen auszuwählen
[cols="1,1,1", frame="none", options="header"]
|===
| 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
|===

[WARNING]
====

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

[[wx-version-detection]]
=== 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.

[[wx-ver-det-example]]
.Installierte wxWidgets-Versionen und -Komponenten feststellen
[example]
====
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.

[.programlisting]
....
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.

[.programlisting]
....
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
....

====

[[wx-defined-variables]]
=== Vordefinierte Variablen

Die folgenden Variablen sind in den Ports verfügbar (nachdem sie entsprechend <<wx-ver-sel-table>> definiert wurden).

.Vordefinierte Variablen für Ports, die wxWidgets verwenden
[cols="1,1", frame="none", options="header"]
|===
| 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.
|===

[[wx-premk]]
=== Verarbeitung in [.filename]#bsd.port.pre.mk#

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

[IMPORTANT]
====
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 [.filename]#bsd.port.pre.mk# geändert werden.
====

[[wx-premk-example]]
.Verwendung von wxWidgets-Variablen in Kommandos
[example]
====
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.

[.programlisting]
....
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
....

====

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

[[wx-additional-config-args]]
=== 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.

.Zulässige Werte für `WX_CONF_ARGS`
[cols="1,1", frame="none", options="header"]
|===
| Möglicher Wert
| Resultierendes Argument

|`absolute`
|`--with-wx-config=${WX_CONFIG}`

|`relative`
|`--with-wx=${LOCALBASE} --with-wx-config=${WX_CONFIG:T}`
|===

[[using-lua]]
== Verwendung von Lua

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

[[lua-introduction]]
=== 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.

[[lua-version]]
=== 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):

[[lua-ver-sel-table]]
.Variablen, um die Lua-Version festzulegen
[cols="1,1,1", frame="none", options="header"]
|===
| 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:

.Verfügbare Lua-Versionen
[cols="1,1", frame="none", options="header"]
|===
| Version
| Port

|`4.0`
|package:lang/lua4[]

|`5.0`
|package:lang/lua50[]

|`5.1`
|package:lang/lua[]
|===

Die Variablen in <<lua-ver-sel-table>> können auf einen oder mehrere (durch Leerzeichen getrennt) der folgenden Werte gesetzt werden:

.Spezifikationen der Lua-Versionen
[cols="1,1", frame="none", options="header"]
|===
| 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.

.Variablen zur Festlegung der bevorzugten Lua-Version
[cols="1,1", frame="none", options="header"]
|===
| Name
| Bestimmt für

|`WANT_LUA_VER`
|den Port

|`WITH_LUA_VER`
|den Benutzer
|===

[[lua-version-example]]
.Auswahl der Lua-Version
[example]
====
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.

[.programlisting]
....
USE_LUA=      5.0-5.1
WANT_LUA_VER= 5.0
....

====

[[lua-components]]
=== 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:

.Verfügbare Lua-Komponenten
[cols="1,1,1", frame="none", options="header"]
|===
| 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`
|===

[NOTE]
====
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 <<lua-def-dep-types>>). Die folgenden Typen sind verfügbar:

.Verfügbare Typen von Lua-Abhängigkeiten
[cols="1,1", frame="none", options="header"]
|===
| 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:

[[lua-def-dep-types]]
.Standardtypen für Lua-Abhängigkeiten
[cols="1,1", frame="none", options="header"]
|===
| 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)
|===

[[lua-components-example]]
.Auswahl von Lua-Komponenten
[example]
====
Der folgende Ausschnitt entspricht einem Port, welcher die Lua-Version `4.0` und die zugehörigen Ruby-Bindungen verwendet.

[.programlisting]
....
USE_LUA=      4.0
LUA_COMPS=    lua ruby
....

====

[[lua-version-detection]]
=== 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.

[[lua-ver-det-example]]
.Installierte Lua-Versionen und- Komponenten feststellen
[example]
====
Der folgende Ausschnitt kann in einem Port verwendet werden, der Lua benutzt, falls es installiert ist oder eine Option dafür ausgewählt wurde.

[.programlisting]
....
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.

[.programlisting]
....
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
....

====

[[lua-defined-variables]]
=== Vordefinierte Variablen

Die folgenden Variablen sind in den Ports verfügbar (nachdem sie entsprechend <<lua-ver-sel-table>> definiert wurden).

.Vordefinierte Variablen für Ports, die Lua verwenden
[cols="1,1", frame="none", options="header"]
|===
| 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 [.filename]#${PREFIX}/bin#, [.filename]#${PREFIX}/share# und [.filename]#${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 ([.filename]#.so#) installiert sind

|`LUA_MODSHAREDIR`
|Das Verzeichnis, in dem Lua-Module ([.filename]#.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
|===

[[lua-variables-example]]
.Einem Port mitteilen, in welchem Verzeichnis Lua liegt
[example]
====
Der folgende Ausschnitt zeigt, wie einem Port, welcher ein configure-Skript verwendet, mitgeteilt werden kann, wo die Lua-Header-Dateien und Bibliotheken liegen.

[.programlisting]
....

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

====

[[lua-premk]]
=== Verarbeitung in [.filename]#bsd.port.pre.mk#

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

[IMPORTANT]
====
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 [.filename]#bsd.port.pre.mk# geändert werden.
====

[[lua-premk-example]]
.Verwendung von Lua-Variablen in Kommandos
[example]
====
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.

[.programlisting]
....
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
....

====

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

[[using-xfce]]
== Xfce verwenden

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

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

* libexo: package:x11/libexo[]
* libgui: package:x11-toolkits/libxfce4gui[]
* libutil: package:x11/libxfce4util[]
* libmcs: package:x11/libxfce4mcs[]
* mcsmanager: package:sysutils/xfce4-mcs-manager[]
* panel: package:x11-wm/xfce4-panel[]
* thunar: package:x11-fm/thunar[]
* wm: package:x11-wm/xfce4-wm[]
* xfdev: package:dev/xfce4-dev-tools[]

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. 
+
[.programlisting]
....
-I${LOCALBASE}/include
	    -L${LOCALBASE}/lib
....

wird CPPFLAGS hinzugefügt und ergibt `CONFIGURE_ENV`.

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

[.programlisting]
....
USE_XFCE=        mcsmanager configenv
....

[[using-mozilla]]
== Mozilla verwenden

.Variablen für Ports, die Mozilla verwenden
[cols="1,1", frame="none"]
|===
|`USE_GECKO`
|Vom Port unterstützte Gecko-Backends. Mögliche Werte sind: `libxul` ([.filename]#libxul.so#), `seamonkey` ([.filename]#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 [.filename]#/usr/ports/Mk/bsd.gecko.mk#.

[[using-databases]]
== Benutzung von Datenbanken

.Variablen für Ports, die Datenbanken benutzen
[cols="1,1", frame="none", options="header"]
|===
| Variable
| Bedeutung

|`USE_BDB`
|Falls die Variable auf `yes` gesetzt ist, füge eine Abhängigkeit von package: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 package: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 package: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 http://www.freebsd.org/cgi/cvsweb.cgi/ports/Mk/bsd.database.mk[ bsd.database.mk].

[[rc-scripts]]
== Starten und Anhalten von Diensten (rc Skripten)

[.filename]#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 [.filename]#rc.d#-Framework. Details zu deren Benutzung können im extref:{handbook}config-tuning/[rc.d Kapitel des Handbuchs, configtuning-rcd] nachgelesen werden. Ausführliche Beschreibungen der verfügbaren Befehle stehen in man:rc[8] und man:rc.subr[8]. Desweiteren gibt es link:{rc-scripting.en}[einen Artikel] zu praktischen Aspekten bezüglich [.filename]#rc.d#-Skripten.

Ein oder mehrere [.filename]#rc.d#-Skripten können installiert werden mittels:

[.programlisting]
....
USE_RC_SUBR=    doormand
....

Skripten müssen im Unterverzeichnis [.filename]#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 <<using-sub-files,zugehörigen Kapitel>> nachgelesen werden.

Für FreeBSD-Versionen, die älter als 6.1-RELEASE sind, ist die Integration mittels man: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 [.filename]#FILESYSTEMS#-Skripten in [.filename]#rc.d# des Basissystems gestartet sein muss.

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

Beispiel eines einfachen [.filename]#rc.d#-Skripts:

[.programlisting]
....
#!/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 

[.programlisting]
....
REQUIRE: LOGIN
....

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

[.programlisting]
....
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 

[.programlisting]
....
doormand_flags=""
....

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

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

=== 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 [.filename]#pkg-plist# sollte eine Zeile wie folgt zugefügt werden:

[.programlisting]
....
@stopdaemon doormand
....

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

[[users-and-groups]]
== 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 [.filename]#ports/UIDs# (für Benutzer) oder [.filename]#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 [.filename]#Makefile# benutzen, um bei der Port-Installation das automatische Anlegen des Benutzers zu veranlassen.

[.programlisting]
....
USERS=  pulse
GROUPS= pulse pulse-access pulse-rt
....

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

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

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

IGNORE=         requires kernel sources to be installed
.endif
....