Einige größere Applikationen können mit einer Reihe von Konfigurationen, die zusätzliche Funktionalitäten hinzufügen, erstellt werden, falls eine oder mehrere Bibliotheken oder Applikationen verfügbar sind. Dazu gehören die Auswahl von natürlichen Sprachen, GUI versus Kommandozeilen-Versionen oder die Auswahl aus mehreren Datenbank-Programmen. Da nicht alle Nutzer diese Bibliotheken oder Applikationen wollen, stellt das Ports-System hooks (Haken) zur Verfügung, damit der Autor des Ports bestimmen kann, welche Konfiguration erstellt werden soll.
Diese Variablen sind entworfen worden, um vom
System-Administrator gesetzt zu werden. Es gibt viele,
die in ports/KNOBS
standardisiert sind.
Benennen Sie Schalter bei der Erstellung eines Ports
nicht programmspezifisch. Verwenden Sie zum Beispiel im
Avahi-Port WITHOUT_MDNS anstelle von
WITHOUT_AVAHI_MDNS.
Sie sollten nicht annehmen, dass ein
WITH_
notwendigerweise eine korrespondierende *
WITHOUT_-Variable
hat oder umgekehrt. Im Allgemeinen wird diese
Vorgabe einfach unterstellt.*
Falls nicht anderweitig festgelegt, werden diese
Variablen nur dahingehend überprüft, ob sie
gesetzt sind oder nicht – nicht darauf,
ob sie auf bestimmte Werte wie YES
oder NO gesetzt sind.
WITH_*
und
WITHOUT_*-Variablen
| Variable | Bedeutung |
|---|---|
WITHOUT_NLS | Falls gesetzt, bedeutet sie, dass eine Internationalisierung nicht benötigt wird, was Kompilierzeit sparen kann. Als Vorgabe wird Internationalisierung gebraucht. |
WITH_OPENSSL_BASE | Nutze die Version von OpenSSL aus dem Basissystem. |
WITH_OPENSSL_PORT | Installiert die Version von OpenSSL aus security/openssl, auch wenn das Basissystem auf aktuellem Stand ist. |
WITHOUT_X11 | Falls der Port mit oder ohne Unterstützung für X erstellt werden kann, dann sollte normalerweise mit X-Unterstützung erstellt werden. Falls die Variable gesetzt ist, soll die Version ohne X-Unterstützung erstellt werden. |
Um die Anzahl der Knobs niedrig zu halten und zum Vorteil des Anwenders, wird empfohlen, dass Porter ähnliche Namen für Knobs verwenden. Eine Liste der beliebtesten Knobs kann in der KNOBS-Datei eingesehen werden.
Knob-Namen sollten wiederspiegeln, was der Knob
bedeutet und was er bewirkt. Wenn ein Port einen
lib-Präfix im PORTNAME hat,
dann soll das lib-Präfix im Knob-Namen
entfallen.
Die OPTIONS-Variable gibt dem
Nutzer, der diesen Port installiert, einen Dialog mit
auswählbaren Optionen und speichert diese in
/var/db/ports/portname/options.
Bei der nächsten Neuerstellung des Ports werden
diese Einstellungen wieder verwandt.
Sie werden sich niemals mehr an all die zwanzig
WITH_ und
*WITHOUT_-Optionen
erinnern müssen, die Sie benutzt haben, um diesen
Port zu erstellen!*
Wenn der Anwender make config
benutzt (oder ein make build das
erste Mal laufen lässt) wird das Framework auf
/var/db/ports/portname/options
die Einstellungen prüfen. Falls die Datei nicht
existiert, werden die Werte von
OPTIONS genutzt, um eine Dialogbox
zu erzeugen, in welcher die Optionen an- oder abgeschaltet
werden können. Dann wird die
options-Datei gespeichert und die
ausgewählten Variablen werden bei der Erstellung
des Ports benutzt.
Falls eine neue Version des Ports
OPTIONS hinzufügt, wird der
Dialog mit den gespeicherten Werten dem Nutzer
angezeigt.
Benutzen Sie make showconfig,
um die gespeicherte Konfiguration zu betrachten.
Benutzen Sie make rmconfig, um die
gespeicherte Konfiguration zu Löschen.
Die Syntax für die
OPTIONS-Variable lautet:
OPTIONS= OPTION "descriptive text" default ...
Der Wert als Vorgabe ist entweder ON
oder OFF. Wiederholungen dieser drei
Felder sind erlaubt.
OPTIONS-Definitionen
müssen vor der Einbindung von
bsd.port.options.mk erscheinen.
Die WITH_* und
WITHOUT_*-Variablen können
nur nach der Einbindung von
bsd.port.options.mk getestet
werden. bsd.port.pre.mk kann auch
stattdessen eingebunden werden und wird immer noch von
vielen Ports eingebunden, die vor der Einführung von
bsd.port.options.mk erstellt wurden.
Jedoch wirken manche Variablen nicht wie gewohnt nach der
Einbindung von bsd.port.pre.mk,
typischerweise USE_*-Optionen.
OPTIONSOPTIONS= FOO "Enable option foo" On \
BAR "Support feature bar" Off
.include <bsd.port.options.mk>
.if defined(WITHOUT_FOO)
CONFIGURE_ARGS+= --without-foo
.else
CONFIGURE_ARGS+= --with-foo
.endif
.if defined(WITH_BAR)
RUN_DEPENDS+= bar:${PORTSDIR}/bar/bar
.endif
.include <bsd.port.mk>OPTIONSOPTIONS= FOO "Enable option foo" On .include <bsd.port.pre.mk> .if defined(WITHOUT_FOO) CONFIGURE_ARGS+= --without-foo .else CONFIGURE_ARGS+= --with-foo .endif .include <bsd.port.post.mk>
Wenn Sie ein GNU-Konfigurationsskript benutzen,
sollten Sie ein Auge darauf werfen, welche Funktionen
durch die automatische Erkennung aktiviert werden.
Schalten Sie Funktionen, die Sie nicht möchten,
ausdrücklich durch Verwendung von
--without-xxx oder
--disable-xxx in der Variable
CONFIGURE_ARGS einzeln ab.
.if defined(WITH_FOO)
LIB_DEPENDS+= foo.0:${PORTSDIR}/devel/foo
CONFIGURE_ARGS+= --enable-foo
.endifStellen Sie sich vor im obigen Beispiel ist eine
Bibliothek libfoo auf dem System installiert. Der Nutzer
will nicht, dass diese Applikation libfoo benutzt, also
hat er die Option auf "off" im
make config-Dialog umgestellt.
Aber das Konfigurationsskript der Applikation hat
erkannt, dass die Bibliothek auf dem System vorhanden ist
und fügt ihre Funktionen in die Binärdatei ein.
Falls der Nutzer sich nun entschliesst libfoo von seinem
System zu entfernen, dann wird das Ports-System nicht
protestieren (es wurde keine Abhängigkeit von libfoo
eingetragen), aber die Applikation bricht ab.
.if defined(WITH_FOO)
LIB_DEPENDS+= foo.0:${PORTSDIR}/devel/foo
CONFIGURE_ARGS+= --enable-foo
.else
CONFIGURE_ARGS+= --disable-foo
.endifIm zweiten Beispiel wird die Bibliothek libfoo explizit abgeschaltet. Das Konfigurationsskript aktiviert die entsprechenden Funktionen nicht in der Applikation trotz der Anwesenheit der Bibliothek auf dem System.
Wenn Sie Fragen zu FreeBSD haben, schicken Sie eine E-Mail an
<de-bsd-questions@de.FreeBSD.org>.
Wenn Sie Fragen zu dieser Dokumentation haben, schicken Sie eine E-Mail an
<de-bsd-translators@de.FreeBSD.org>.