Kapitel 5. Die Konfiguration des Makefile

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Hier ist das Prozedere:

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

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

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

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

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

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

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

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

Oder verwenden Sie ein kondensiertes Format:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Zum Beispiel wird

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

immer zum jpeg -Port wechseln und ihn extrahieren.

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

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

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

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

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

oder möglicherweise

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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