USE_LDCONFIG= yes
This translation may be out of date. To help with the translations please access the FreeBSD translations instance .
Es gibt einige Dinge mehr, die zu beachten sind, wenn man einen Port erstellt. Dieser Abschnitt erklärt die wichtigsten.
Wenn Ihr Port eine oder mehrere Shared-Libraries installiert, dann definieren Sie bitte eine
USE_LDCONFIG
make-Variable, die
bsd.port.mk
anweisen wird,
${LDCONFIG} -m
auf das Verzeichnis, in das die neue Library installiert wird (normalerweise
PREFIX/lib
), während des
post-install
-Targets anzuwenden, um sie im Shared-Library-Cache zu registrieren. Diese Variable, wenn definiert, wird auch dafür sorgen, dass ein entsprechendes
@exec /sbin/ldconfig -m
und
@unexec /sbin/ldconfig -R
-Paar zu Ihrer
pkg-plist
-Datei hinzugefügt wird, sodass ein Benutzer, der das Paket installiert, die Bibliothek danach sofort benutzen kann und das System nach deren Deinstallation nicht glaubt, die Bibliothek wäre noch da.
USE_LDCONFIG= yes
Wenn nötig, können Sie das Standardverzeichnis außer Kraft setzen, indem Sie den
USE_LDCONFIG
Wert auf eine Liste von Verzeichnissen setzen, in die Shared Libraries installiert werden sollen. Wenn Ihr Port z.B. diese Bibliotheken nach
PREFIX/lib/foo
und
PREFIX/lib/bar
installiert, könnten Sie folgendes in Ihrem
Makefile
benutzen:
USE_LDCONFIG= ${PREFIX}/lib/foo ${PREFIX}/lib/bar
Bitte überprüfen Sie dies genau. Oft ist das überhaupt nicht nötig oder kann durch
-rpath
oder das Setzen von
LD_RUN_PATH
während des Linkens umgangen werden (s.
lang/moscow_ml
für ein Beispiel), oder durch einen Shell-Wrapper, der
LD_LIBRARY_PATH
setzt, bevor er die Binärdatei ausführt, wie es
www/seamonkey
tut.
Wenn Sie 32-Bit Libraries auf 64-Bit Systemen installieren, benutzen Sie stattdessen
USE_LDCONFIG32
.
Versuchen Sie Shared-Library-Versionsnummern im libfoo.so.0 Format zu halten. Unser Runtime-Linker kümmert sich nur um die Major (erste) Nummer.
Wenn sich die Major-Library-Versionsnummer während der Aktualisierung zu einer neuen Portversion erhöht, sollte auch die
PORTREVISION
aller Ports, die die Shared-Library linken, erhöht werden, damit diese mit der neuen Version der Bibliothek neu kompiliert werden.
Lizenzen variieren und manche geben Restriktionen vor, wie die Applikation gepackt werden oder ob sie gewinnorientiert verkauft werden kann, usw.
|
Es liegt in Ihrer Verantwortung als Porter die Lizenzbestimmungen der Software zu lesen und sicherzustellen, dass das FreeBSD-Projekt nicht haftbar gemacht wird für Lizenzverletzungen durch Weiterverbreitung des Quelltextes oder kompilierter Binaries über FTP/HTTP oder CD-ROM. Im Zweifelsfall kontaktieren Sie bitte die FreeBSD ports . |
In solchen Situationen können die in den folgenden Abschnitten beschriebenen Variablen gesetzt werden.
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 /usr/ports/LEGAL hinzufügen sollte, der genau beschreibt, was die Beschränkung mit sich bringt.
Das Ports-Framework von FreeBSD unterstützt das parallele Bauen von Ports, indem es mehrere
make
-Instanzen ausführt, damit SMP-Systeme ihre gesamte CPU-Rechenleistung ausnützen können und so das Bauen von Ports schneller und effektiver werden kann.
Dies ermöglicht der Parameter
-jX
an
make(1)
, wenn Code von Drittanbietern kompiliert wird. Leider können nicht alle Ports wirklich gut mit dem Parallelbau umgehen. Deshalb ist es erforderlich, dass dieses Feature explizit durch
MAKE_JOBS_SAFE=yes
irgendwo unterhalb des Abschnitts für Abhängigkeiten im
Makefile
aktiviert wird.
Eine weitere Möglichkeit im Umgang mit dieser Option besteht für den Maintainer darin,
MAKE_JOBS_UNSAFE=yes
zu setzen. Diese Variable wird dann verwendet, wenn ein Port bekannterweise mit
-jX
nicht gebaut werden kann, der Benutzer jedoch für alle Ports den Mehrprozessorbau durch
FORCE_MAKE_JOBS=yes
in
/etc/make.conf
erzwingt.
make
,
gmake
und
imake
Wenn Ihr Port GNU make benutzt, dann setzen Sie bitte
USE_GMAKE=yes
.
| Variable | Bedeutung |
|---|---|
|
|
Der Port benötigt
|
|
|
Der ganze Pfad zu
|
Wenn Ihr Port eine X-Applikation ist, die
Makefile
-Dateien aus
Imakefile
-Dateien mit imake erzeugt, dann setzen Sie
USE_IMAKE=yes
. Das sorgt dafür, dass die Konfigurationsphase automatisch ein
xmkmf -a
ausführt. Wenn das Flag
-a
ein Problem für Ihren Port darstellt, setzen Sie
XMKMF=xmkmf
. Wenn der Port imake benutzt, aber das
install.man
-Target nicht versteht, dann sollte
NO_INSTALL_MANPAGES=yes
gesetzt werden.
Wenn das
Makefile
im Quelltext Ihres Ports etwas anderes als
all
als Haupt-Build-Target hat, setzen Sie
ALL_TARGET
entsprechend. Das Gleiche gilt für
install
und
INSTALL_TARGET
.
configure
Skript
Wenn Ihr Port ein
configure
-Skript benutzt, um
Makefile
-Dateien aus
Makefile.in
-Dateien zu erzeugen, setzen Sie
GNU_CONFIGURE=yes
. Wenn Sie dem
configure
-Skript zusätzliche Argumente übergeben wollen (das Vorgabeargument ist
--prefix=${PREFIX} --infodir=${PREFIX}/${INFO_PATH} --mandir=${MANPREFIX}/man --build=${CONFIGURE_TARGET}
), setzen Sie diese zusätzlichen Argumente in
CONFIGURE_ARGS
. Zusätzliche Umgebungsvariablen können überdie Variable
CONFIGURE_ENV
übergeben werden.
| Variable | Bedeutung |
|---|---|
|
|
Der Port benutzt ein
|
|
|
Wie
|
|
|
Zusätzliche Argumente für das
|
|
|
Zusätzliche Umgebungsvariablen für die Abarbeitung des
|
|
|
Ersetzt das Standard-Konfigurations-Target. Vorgabewert ist
|
scons
Wenn Ihr Port SCons benutzt, definieren Sie
USE_SCONS=yes
.
| Variable | Bedeutung |
|---|---|
|
|
Port-spezifische SCons-Argumente, die der SCons-Umgebung übergeben werden. |
|
|
Variablen, die in der System-Umgebung gesetzt werden sollen. |
|
|
Variablen, die in der SCons-Umgebung gesetzt werden sollen. |
|
|
Letztes Argument, das SCons übergeben wird - ähnlich
|
Um
SConstruct
im Quelltext alles, was SCons in
SCONS_ENV
übergeben wird, respektieren zu lassen (das ist hauptsächlich
CC/CXX/CFLAGS/CXXFLAGS
), patchen Sie
SConstruct
, sodass das Build
Environment
wie folgt konstruiert wird:
env = Environment(**ARGUMENTS)
Es kann dann mit
env.Append
und
env.Replace
modifiziert werden.
Die verschiedenen GNU autotools stellen einen Abstraktionsmechanismus bereit für das Kompilieren von Software für eine Vielfalt von Betriebssystemen und Maschinenarchitekturen. Innerhalb der Ports-Sammlung kann ein einzelner Port diese Werkzeuge mit Hilfe eines einfachen Konstrukts benutzen:
USE_AUTOTOOLS= tool:version[:operation] ...
Als dies geschrieben wurde konnte
tool
eins von
libtool
,
libltdl
,
autoconf
,
autoheader
,
automake
oder
aclocal
sein.
version
gibt die einzelne Werkzeug-Revision an, die benutzt werden soll (siehe
devel/{automake,autoconf,libtool}[0-9]+
für mögliche Versionen).
operation ist eine optionale Angabe, die modifiziert, wie das Werkzeug benutzt wird.
Es können auch mehrere Werkzeuge angegeben werden - entweder durch Angabe aller in einer einzigen Zeile oder durch Benutzung des
+=
Makefile-Konstrukts.
Schliesslich gibt es das spezielle Tool, genannt
autotools
, das der Einfachheit dient indem es von alle verfügbaren Versionen der Autotools abhängt, was sinnvoll für Cross-Development ist. Dies kann auch erreicht werden, indem man den Port
devel/autotools
installiert.
libtool
Shared-Libraries, die das GNU Build-System benutzen, verwenden normalerweise
libtool
, um die Kompilierung und Installation solcher Bibliotheken anzupassen. Die übliche Praxis ist, eine Kopie von
libtool
, die mit dem Quelltext geliefert wird, zu benutzen. Falls Sie ein externes
libtool
benötigen, können Sie die Version, die von der Ports-Sammlung bereitgestellt wird, benutzen:
USE_AUTOTOOLS= libtool:version[:env]
Ohne zusätzliche Angaben sagt
libtool:version
dem Build-System, dass es das Konfigurationsskript mit der auf dem System installierten Kopie von
libtool
patchen soll. Die Variable
GNU_CONFIGURE
ist impliziert. Außerdem werden einige make- und shell-Variablen zur weiteren Benutzung durch den Port gesetzt. Für Genaueres siehe
bsd.autotools.mk
.
Mit der Angabe
:env
wird nur die Umgebung vorbereitet.
Schließlich können optional
LIBTOOLFLAGS
und
LIBTOOLFILES
gesetzt werden, um die häufigsten Argumente und durch
libtool
gepatchten Dateien außer Kraft zu setzen. Die meisten Ports werden das aber nicht brauchen. Für Weiteres siehe
bsd.autotools.mk
.
libltdl
Einige Ports benutzen das
libltdl
-Bibliothekspaket, welches Teil der
libtool
-Suite ist. Der Gebrauch dieser Bibliothek macht nicht automatisch den Gebrauch von
libtool
selbst nötig, deshalb wird ein separates Konstrukt zur Verfügung gestellt.
USE_AUTOTOOLS= libltdl:version
Im Moment sorgt dies nur für eine
LIB_DEPENDS
-Abhängigkeit von dem entsprechenden
libltdl
-Port und wird zur Vereinfachung zur Verfügung gestellt, um Abhängigkeiten von den Autotools-Ports ausserhalb des
USE_AUTOTOOLS
-Systems zu eliminieren. Es gibt keine weiteren Angaben für dieses Werkzeug.
autoconf
und
autoheader
Manche Ports enthalten kein Konfigurationsskript, sondern eine autoconf-Vorlage in der
configure.ac
-Datei. Sie können die folgenden Zuweisungen benutzen, um
autoconf
das Konfigurationsskript erzeugen zu lassen, und auch
autoheader
Header-Vorlagen zur Benutzung durch das Konfigurationsskript erzeugen zu lassen.
USE_AUTOTOOLS= autoconf:version[:env]
und
USE_AUTOTOOLS= autoheader:version
welches auch die Benutzung von
autoconf:version
impliziert.
Ähnlich wie bei
libtool
, bereitet die Angabe des optionalen
:env
nur die Umgebung für weitere Benutzung vor. Ohne dieses wird der Port auch gepatched und erneut konfiguriert.
Die zusätzlichen optionalen Variablen
AUTOCONF_ARGS
und
AUTOHEADER_ARGS
können durch das
Makefile
des Ports ausser Kraft gesetzt werden, wenn erforderlich. Wie bei den
libtool
-Äquivalenten werden die meisten Ports dies aber nicht benötigen.
automake
und
aclocal
Manche Pakete enthalten nur
Makefile.am
-Dateien. Diese müssen durch
automake
in
Makefile.in
-Dateien konvertiert und dann durch
configure
weiterbearbeitet werden, um schließlich ein
Makefile
zu erzeugen.
Ähnliches gilt für Pakete, die gelegentlich keine
aclocal.m4
-Dateien mitliefern, welche ebenfalls zum Erstellen der Software benötigt werden. Diese können durch
aclocal
erzeugt werden, welches
configure.ac
oder
configure.in
durchsucht.
aclocal
hat eine ähnliche Beziehung zu
automake
wie
autoheader
zu
autoconf
- beschrieben im vorherigen Abschnitt.
aclocal
impliziert die Benutzung von
automake
, also haben wir:
USE_AUTOTOOLS= automake:version[:env]
und
USE_AUTOTOOLS= aclocal:version
was auch die Benutzung von
automake:version
impliziert.
Ähnlich wie bei
libtool
und
autoconf
, bereitet die optionale Angabe
:env
nur die Umgebung zur weiteren Benutzung vor. Ohne sie wird der Port erneut konfiguriert.
Wie schon
autoconf
und
autoheader
, hat sowohl
automake
als auch
aclocal
eine optionale Argument-Variable
AUTOMAKE_ARGS
bzw.
ACLOCAL_ARGS
, die durch das
Makefile
des Ports, falls nötig, außer Kraft gesetzt werden kann.
gettext
Wenn Ihr Port
gettext
benötigt, setzen Sie einfach
USE_GETTEXT
auf
yes
, und Ihr Port bekommt die Abhängigkeit von
devel/gettext
. Der Wert von
USE_GETTEXT
kann auch die benötigte Version der
libintl
-Bibliothek angeben, der grundlegenden Teil von
gettext
- jedoch wird von der Benutzung dieser Funktion
dringend abgeraten
: Ihr Port sollte einfach nur mit der aktuellen Version von
devel/gettext
funktionieren.
Ein ziemlich häufiger Fall ist, dass ein Port
gettext
und
configure
benutzt. Normalerweise sollte GNU
configure gettext
automatisch finden können. Sollte das einmal nicht funktionieren, können Hinweise über den Ort von
gettext
in
CPPFLAGS
und
LDFLAGS
wie folgt übergeben werden:
USE_GETTEXT= yes
CPPFLAGS+= -I${LOCALBASE}/include
LDFLAGS+= -L${LOCALBASE}/lib
GNU_CONFIGURE= yes
CONFIGURE_ENV= CPPFLAGS="${CPPFLAGS}" \
LDFLAGS="${LDFLAGS}"
Natürlich kann der Code kompakter sein, wenn es keine weiteren Flags gibt, die
configure
übergeben werden müssen:
USE_GETTEXT= yes
GNU_CONFIGURE= yes
CONFIGURE_ENV= CPPFLAGS="-I${LOCALBASE}/include" \
LDFLAGS="-L${LOCALBASE}/lib"
Manche Softwareprodukte erlauben die Deaktivierung von NLS - z.B. durch Übergeben von
--disable-nls
an
configure
. In diesem Fall sollte Ihr Port
gettext
abhängig vom Status von
WITHOUT_NLS
benutzen. Für Ports mit niedriger bis mittlerer Komplexität können Sie sich auf das folgende Idiom verlassen:
GNU_CONFIGURE= yes .if !defined(WITHOUT_NLS) USE_GETTEXT= yes PLIST_SUB+= NLS="" .else CONFIGURE_ARGS+= --disable-nls PLIST_SUB+= NLS="@comment " .endif
Der nächste Punkt auf Ihrer Todo-Liste ist dafür zu sorgen, dass die Message-Catalog-Dateien nur bedingt in der Packliste aufgeführt werden. Der
Makefile
-Teil dieser Aufgabe ist schon durch obiges Idiom erledigt. Das wird im Abschnitt über
Fortgeschrittene
pkg-plist
-Methoden
erklärt. Kurz gesagt, jedes Vorkommen von
%%NLS%%
in
pkg-plist
wird durch “@comment”, wenn NLS abgeschaltet ist, oder durch eine leere Zeichenkette, wenn NLS aktiviert ist, ersetzt. Folglich werden die Zeilen, denen
%%NLS%%
vorangestellt ist, zu reinen Kommentaren in der endgültigen Packliste, wenn NLS abgeschaltet ist; andernfalls wird der Prefix einfach nur ausgelassen. Alles, was Sie jetzt noch machen müssen, ist
%%NLS%%
vor jedem Pfad zu einer Message-Catalog-Datei in
pkg-plist
einzufügen. Zum Beispiel:
%%NLS%%share/locale/fr/LC_MESSAGES/foobar.mo %%NLS%%share/locale/no/LC_MESSAGES/foobar.mo
In sehr komplexen Fällen müssen Sie eventuell fortgeschrittenere Techniken als die hier vorgestellte benutzen - wie z.B. Dynamische Packlistenerzeugung .
Bei der Installation von Message-Catalog-Dateien gibt es einen Punkt zu beachten. Ihr Zielverzeichnis, das unter LOCALBASE/shared/locale liegt, sollte nur selten von Ihrem Port erzeugt und gelöscht werden. Die Verzeichnisse für die gebräuchlichsten Sprachen sind in /etc/mtree/BSD.local.dist aufgelistet; das heisst, sie sind Teil des Systems. Die Verzeichnisse für viele andere Sprachen sind Teil des Ports devel/gettext . Sie wollen vielleicht dessen pkg-plist zur Hand nehmen, um festzustellen, ob Ihr Port eine Message-Catalog-Datei für eine seltene Sprache installiert.
perl
Wenn
MASTER_SITES
auf
MASTER_SITE_PERL_CPAN
gesetzt ist, dann ist der bevorzugte Wert von
MASTER_SITE_SUBDIR
der Top-Level-Name der Hierarchie. Zum Beispiel ist der empfohlene Wert für
p5-Module-Name
-
Module
. Die Top-Level-Hierarchie kann unter
cpan.org
angeschaut werden. Dies sorgt dafür, dass der Port weiter funktioniert, wenn sich der Autor des Moduls ändert.
Die Ausnahme dieser Regel ist, dass das entsprechende Verzeichnis selber oder das Distfile in diesem Verzeichnis nicht existiert. In solchen Fällen ist die Benutzung der Id des Autors als
MASTER_SITE_SUBDIR
erlaubt.
Jede der Einstellungen unten kann sowohl auf
YES
als auch auf eine Versionszeichenkette wie
5.8.0+
gesetzt werden. Wenn
YES
benutzt wird, bedeutet das, dass der Port mit jeder der unterstützten Perl-Versionen funktioniert. Falls ein Port nur mit einer bestimmten Perl-Version funktioniert, kann darauf mit einer Versionszeichenkette hingewiesen werden, die entweder eine Mindest- (z.B.
5.7.3+
), Maximal- (z.B.
5.8.0-
) oder Absolutversion (z.B.
5.8.3
) festlegt.
| Variable | Bedeutung |
|---|---|
|
|
Bedeutet, dass der Port
|
|
|
Bedeutet, dass der Port
|
|
|
Bedeutet, dass der Port
|
|
|
Der gesamte Pfad zu
|
|
|
Perls MakeMaker für die Konfiguration benutzen. Dies impliziert
|
|
|
Module::Build für configure, build und install benutzen. Dies impliziert
|
|
Ports von Perl-Modulen, die keine offizielle Webseite haben, sollen in der WWW-Zeile ihrer
pkg-descr
-Datei auf
|
Die X11-Implementierung, welche die Ports-Sammlung bereitstellt, ist X.Org. Wenn Ihre Applikation von X-Komponenten abhängt, listen Sie die benötigten Komponenten in
USE_XORG
auf. Als dies geschrieben wurde, wurden die folgenden Komponenten bereitgestellt:
bigreqsproto compositeproto damageproto dmx dmxproto evieproto fixesproto fontcacheproto fontenc fontsproto fontutil glproto ice inputproto kbproto libfs oldx printproto randrproto recordproto renderproto resourceproto scrnsaverproto sm trapproto videoproto x11 xau xaw xaw6 xaw7 xaw8 xbitmaps xcmiscproto xcomposite xcursor xdamage xdmcp xevie xext xextproto xf86bigfontproto xf86dgaproto xf86driproto xf86miscproto xf86rushproto xf86vidmodeproto xfixes xfont xfontcache xft xi xinerama xineramaproto xkbfile xkbui xmu xmuu xorg-server xp xpm xprintapputil xprintutil xpr oto xproxymngproto xrandr xrender xres xscrnsaver xt xtrans xtrap xtst xv xvmc xxf86dga xxf86misc xxf86vm
.
Die aktuelle Liste finden Sie immer in /usr/ports/Mk/bsd.xorg.mk .
Das Mesa Projekt ist ein Versuch, eine freie OpenGL Implementierung bereitzustellen. Sie können eine Abhängigkeit von verschiedenen Komponenten diese Projektes in der Variable
USE_GL
spezifizieren. ouml;gliche Optionen sind:
glut, glu, glw, glew, gl
und
linux
. Für Abwärtskompatibilität gilt der Wert
yes
als
glu
.
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.
|
|
Der Port benutzt die X-Bibliotheken. Soll nicht mehr verwendet werden - benutzen Sie stattdessen eine Liste von Komponenten in
|
|
|
Soll nicht mehr benutzt werden, ist jetzt äquivalent zu
|
|
|
Der Port benutzt
|
|
|
Ist auf den Pfad zu
|
|
|
Ein Port, der
|
|
|
Ein Port, der die X11-Bibliotheken bereitstellt. |
|
|
Ein Port, der X11-Clients bereitstellt. |
|
|
Ein Port, der den X11-Server bereitstellt. |
|
|
Ein Port, der den Fontserver bereitstellt. |
|
|
Ein Port, der den Printserver bereitstellt. |
|
|
Ein Port, der den virtuellen Framebuffer-Server bereitstellt. |
|
|
Ein Port, der einen nested X-Server bereitstellt. |
|
|
Ein Port, der Kodierungen für Schriftarten bereitstellt. |
|
|
Ein Port, der verschiedene Bitmap-Schriftarten bereitstellt. |
|
|
Ein Port, der 100dpi Bitmap-Schriftarten bereitstellt. |
|
|
Ein Port, der 75dpi Bitmap-Schriftarten bereitstellt. |
|
|
Ein Port, der kyrillische Bitmap-Schriftarten bereitstellt. |
|
|
Ein Port, der TrueType®-Schriftarten bereitstellt. |
|
|
Ein Port, der Type1-Schriftarten bereitstellt. |
|
|
Ein Port, der entwicklerorientierte Manualpages bereitstellt. |
# 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
Wenn Ihr Port eine Motif-Bibliothek benötigt, definieren Sie
USE_MOTIF
im
Makefile
. Die Standard-Motif-Implementierung ist
x11-toolkits/open-motif
. Benutzer können stattdessen
x11-toolkits/lesstif
wählen, indem Sie die
WANT_LESSTIF
-Variable setzen.
Die Variable
MOTIFLIB
wird von
bsd.port.mk
auf die entsprechende Motif-Bibliothek gesetzt. Bitte patchen Sie den Quelltext Ihres Ports, sodass er überall
${MOTIFLIB}
benutzt, wo die Motif-Bibliothek im Original
Makefile
oder
Imakefile
referenziert wird.
Es gibt zwei verbreitete Fälle:
Wenn sich der Port in seinem
Makefile
oder
Imakefile
auf die Motif-Bibliothek als
-lXm
bezieht, ersetzen Sie das einfach durch
${MOTIFLIB}
.
Wenn der Port in seinem
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.
Wenn Ihr Port Schriftarten für das X-Window-System installiert, legen Sie diese nach LOCALBASE/lib/X11/fonts/local .
DISPLAY
durch Xvfb
Manche Applikationen benötigen ein funktionierendes X11-Display, damit die Kompilierung funktioniert. Das stellt für Systeme, die ohne Display laufen, ein Problem dar. Wenn die folgende Variable benutzt wird, startet die Bauumgebung den virtuellen Framebuffer-X-Server, und ein funktionierendes
DISPLAY
wird dem Build übergeben.
USE_DISPLAY= yes
Desktop-Einträge (
Freedesktop Standard
) können in Ihrem Port einfach über die
DESKTOP_ENTRIES
-Variable erzeugt werden. Diese Einträge erscheinen dann im Applikationsmenü von standardkonformen Desktop-Umgebungen wie GNOME oder KDE. Die
.desktop
-Datei wird dann automatisch erzeugt, installiert und der
pkg-plist
hinzugefügt. Die Syntax ist:
DESKTOP_ENTRIES= "NAME" "COMMENT" "ICON" "COMMAND" "CATEGORY" StartupNotify
Die Liste der möglichen Kategorien ist auf der
Freedesktop Webseite
abrufbar.
StartupNotify
zeigt an, ob die Applikation den Status in Umgebungen, die Startup-Notifications kennen, löschen wird.
Beispiel:
DESKTOP_ENTRIES= "ToME" "Roguelike game based on JRR Tolkien's work" \
"${DATADIR}/xtra/graf/tome-128.png" \
"tome -v -g" "Application;Game;RolePlaying;" \
false
Das FreeBSD/GNOME-Projekt benutzt seine eigene Gruppe von Variablen, um zu definieren, welche GNOME-Komponenten ein bestimmter Port benutzt. Eine umfassende Liste dieser Variablen existiert innerhalb der Webseite des FreeBSD/GNOME-Projektes.
|
|
Der Port benutzt das Qt-Toolkit. Mögliche Werte sind
|
|
|
Enthält den Pfad, wohin Qt installiert ist (nur lesbare Variable). |
|
|
Enthält den Pfad von
|
|
|
Zusätzliche Compiler-Flags, die über
|
|
|
Zusätzliche Bibliotheken, die über
|
|
|
Änderungen von
|
|
|
Spezifiziert Tool- und Bibliothek-Abhängigkeiten für Qt4. Siehe unten für Details. |
|
|
Enthält den Pfad von
|
|
|
Enthält den Pfad von
|
|
|
Enthält den Pfad der Konfigurationsdatei für
|
Wenn
USE_QT_VER
gesetzt ist, werden dem
configure
-Skript einige nützliche Einstellungen übergeben:
CONFIGURE_ARGS+= --with-qt-includes=${QT_PREFIX}/include \
--with-qt-libraries=${QT_PREFIX}/lib \
--with-extra-libs=${LOCALBASE}/lib \
--with-extra-includes=${LOCALBASE}/include
CONFIGURE_ENV+= MOC="${MOC}" CPPFLAGS="${CPPFLAGS} ${QTCPPFLAGS}" LIBS="${QTCFGLIBS}" \
QTDIR="${QT_PREFIX}" KDEDIR="${KDE_PREFIX}"
Wenn
USE_QT_VER
auf
4
gesetzt ist, werden auch die folgenden Einstellungen übergeben:
CONFIGURE_ENV+= UIC="${UIC}" QMAKE="${QMAKE}" QMAKESPEC="${QMAKESPEC}"
MAKE_ENV+= QMAKESPEC="${QMAKESPEC}"
Wenn
USE_QT_VER
auf 4 gesetzt ist, können individuelle Qt4-Tool- und Bibliotheksabhängigkeiten in der Variable
QT_COMPONENTS
angegeben werden. An jede Komponente kann
_build
oder
_run
als Suffix angehängt werden, was eine Abhängigkeit zur Build- bzw. Laufzeit angibt. Ohne Suffix gilt die Abhängigkeit sowohl zur Build- als auch zur Laufzeit. Bibliothekskomponenten sollten normalerweise ohne Suffix angegeben werden, Tool-Komponenten mit
_build
und Plugin-Komponenten mit
_run
. Die gebräuchlichsten Komponenten werden im Folgenden angegeben (alle verfügbaren Komponenten sind in
_QT_COMPONENTS_ALL
in
/usr/ports/Mk/bsd.qt.mk
aufgelistet):
| Name | Beschreibung |
|---|---|
|
|
Kern-Bibliothek (kann weggelassen werden- es sei denn, der Port benutzt nichts außer
|
|
|
Graphische Benutzeroberflächen-Bibliothek |
|
|
Netzwerk-Bibliothek |
|
|
OpenGL-Bibliothek |
|
|
Qt3-Kompatibilitäts-Bibliothek |
|
|
Modultest-Bibliothek |
|
|
Skript-Bibliothek |
|
|
SQL-Bibliothek |
|
|
XML-Bibliothek |
Sie können herausfinden, welche Bibliotheken die Applikation benötigt, indem Sie nach erfolgreicher Kompilierung
ldd
auf die Hauptbinärdatei anwenden.
| Name | Beschreibung |
|---|---|
|
|
meta object compiler (wird zum Build fast jeder Qt-Applikation benötigt) |
|
|
Makefile-Generator / Build-Werkzeug |
|
|
Resource-Compiler (wird benötigt, falls die Applikation .rc oder .qrc Dateien enthält) |
|
|
User-Interface-Compiler (wird benötigt, falls die Applikation von Qt-Designer erzeugte *.ui Dateien enthält - gilt für praktisch jede Qt-Applikation mit einer GUI) |
| Name | Beschreibung |
|---|---|
|
|
SVG-Icon-Engine Plugin (wenn die Applikation SVG-Icons mitliefert) |
|
|
Bildformatplugins für GIF, JPEG, MNG und SVG (wenn die Applikation Bilddateien mitliefert) |
In diesem Beispiel benutzt die portierte Applikation die Qt4 GUI-Bibliothek, die Qt4-Core-Bibliothek, alle Qt4-Codeerzeugungstools und Qt4’s Makefile Generator. Da die GUI-Bibliothek eine Abhängigkeit von der Core-Bibliothek impliziert, muss corelib nicht angegeben werden. Die Qt4-Codeerzeugungstools moc, uic und rcc, sowie der Makefile Generator qmake werden nur für den Build benötigt, deshalb bekommen die den Suffix
_build
:
USE_QT_VER= 4 QT_COMPONENTS= gui moc_build qmake_build rcc_build uic_build
Wenn die Applikation keine configure Datei, sondern eine .pro Datei hat, können Sie das Folgende benutzen:
HAS_CONFIGURE= yes
do-configure:
@cd ${WRKSRC} && ${SETENV} ${CONFIGURE_ENV} \
${QMAKE} -unix PREFIX=${PREFIX} texmaker.pro
Beachten Sie die Ähnlichkeit mit der
qmake
-Zeile im mitgelieferten
BUILD.sh
-Skript. Die Übergabe von
CONFIGURE_ENV
stellt sicher, dass
qmake
die
QMAKESPEC
-Variable übergeben bekommt, ohne die es nicht funktioniert.
qmake
erzeugt Standard-Makefiles, sodass es nicht nötig ist ein eigenes neues
build
-Target zu schreiben.
Qt-Applikationen sind oft so geschrieben, dass sie plattformübergreifend sind, und oft ist X11/Unix nicht die Plattform, auf der sie entwickelt werden. Das sorgt oft für bestimmte fehlende Kleinigkeiten wie z.B.:
Fehlende zusätzliche Include-Pfade.
Viele Applikationen kommen mit System-Tray-Icon Support- unterlassen es aber Includes oder Bibliotheken in den X11 Verzeichnissen zu suchen. Sie können
qmake
über die Kommandozeile sagen, es soll Verzeichnisse zu den Include- und Bibliotheks-Suchpfaden hinzufügen - z.B.:
${QMAKE} -unix PREFIX=${PREFIX} INCLUDEPATH+=${LOCALBASE}/include \
LIBS+=-L${LOCALBASE}/lib sillyapp.pro
Falsche Installations-Pfade. Manchmal werden Daten wie Icons oder .desktop-Dateien per Vorgabe in Verzeichnisse installiert, die nicht von XDG-kompatiblen Applikationen durchsucht werden. editors/texmaker ist hierfür ein Beispiel- siehe patch-texmaker.pro im files -Verzeichnis dieses Ports als eine Vorlage, die zeigt, wie man dies direkt in der Qmake Projektdatei löst.
|
|
Der Port benutzt KDE-Bibliotheken. Die Variable spezifiziert die Major Version von KDE, die benutzt werden soll, und impliziert
|
|
|
Der Port benutzt die KDE-Base. Die Variable spezifiziert die Major Version von KDE, die benutzt werden soll, und impliziert
|
Falls Ihre Anwendung von KDE 4 abhängt, weisen Sie
USE_KDE4
eine Liste mit benötigten Komponenten zu. Die am häufigsten gebrauchten sind unten aufgelistet (
_USE_KDE4_ALL
in
/usr/ports/Mk/bsd.kde4.mk
enthält stets die aktuelle Liste):
| Name | Beschreibung |
|---|---|
|
|
Personal Information Management (PIM)-Speicherdienst |
|
|
Lässt den Port das Bauwerkzeug automoc4 verwenden. |
|
|
Grundlegende KDE-Anwendungen (Konqueror, Dolphin, Konsole) |
|
|
Experimentelle KDE-Bibliotheken (mit einer API, die als non-stable eingestuft ist) |
|
|
Stellt allgemeine KDE-Verzeichnisse bereit |
|
|
Die grundlegenden KDE-Bibliotheken |
|
|
Falls in der Liste vorhanden, wird der Port unter
|
|
|
PIM-Bibliotheken |
|
|
Anwendungen und Bibliotheken, welche die Desktopumgebung gestalten (Plasma, KWin) |
KDE 4-Ports werden unter
${KDE4_PREFIX}
, zur Zeit
/usr/local/kde4
, installiert, um Konflikte mit KDE 3-Ports zu verhindern. Dies wird durch Auflisten der Komponente
kdeprefix
erreicht, welche die standardmäßig gesetzte Variable
PREFIX
überschreibt. Die Ports übernehmen jedoch, jeden über die Umgebungsvariable
MAKEFLAGS
oder make-Parameter festgelegten Wert für
PREFIX
.
Es könnte bei der Installation von KDE 4-Ports zu Konflikten mit KDE 3-Ports kommen, sodass diese bei aktivierter
kdeprefix
-Komponente unter
${KDE4_PREFIX}
installiert werden. Der Standardwert von
KDE4_PREFIX
ist zur Zeit
/usr/local/kde4
. Es ist auch möglich, KDE 4-Ports unter einem angepassten
PREFIX
zu installieren. Wenn
PREFIX
als
MAKEFLAGS
-Umgebungsvariable oder als make-Parameter gesetzt wird, überschreibt dies den von
kdeprefix
festgelegten Wert.
USE_KDE4
-Beispiel
Dies ist ein einfaches Beispiel für einen KDE 4-Port.
USE_CMAKE
weist den Port an, CMake, ein unter KDE 4-Projekten weit verbreitetes Konfigurationswerkzeug, zu verwenden.
USE_KDE4
legt die Abhängigkeit von KDE-Bibliotheken und die Verwendung von automoc4 während der Kompilierung fest. Mit Hilfe des configure-Protokolls können die KDE-Komponenten und andere Abhängigkeiten festgestellt werden.
USE_KDE4
impliziert
USE_QT_VER
nicht. Falls der Port Qt 4-Komponenten benötigt, sollten
USE_QT_VER
gesetzt und verlangte Komponenten festgelegt werden.
USE_CMAKE= yes USE_KDE4= automoc4 kdelibs kdeprefix USE_QT_VER= 4 QT_COMPONENTS= qmake_build moc_build rcc_build uic_build
Wenn Ihr Port ein Java™ Development Kit (JDK™) benötigt, entweder zum Bauen, zur Laufzeit oder sogar, um das Distfile auszupacken, dann sollten Sie
USE_JAVA
setzen.
Es gibt mehrere JDKs in der Ports-Sammlung- von verschiedenen Anbietern und in verschiedenen Versionen. Wenn Ihr Port eine bestimmte dieser Versionen benötigt, können Sie definieren welche. Die aktuelle Version ist java/jdk16 .
| Variable | Bedeutung |
|---|---|
|
|
Sollte definiert sein, damit die übrigen Variablen irgendeinen Effekt haben. |
|
|
Durch Leerzeichen getrennte Liste von geeigneten Java-Versionen für den Port. Ein optionales
|
|
|
Durch Leerzeichen getrennte Liste von geeigneten JDK-Port-Betriebssystemen für den Port. (erlaubte Werte:
|
|
|
Durch Leerzeichen getrennte Liste von geeigneten JDK-Port-Anbietern für den Port. (erlaubte Werte:
|
|
|
Bedeutet, falls gesetzt, dass der ausgewählte JDK-Port zu den Build-Abhängigkeiten des Ports hinzugefügt werden soll. |
|
|
Bedeutet, falls gesetzt, dass der ausgewählte JDK-Port zu den Laufzeit-Abhängigkeiten des Ports hinzugefügt werden soll. |
|
|
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:
| Variable | Wert |
|---|---|
|
|
Der Name des JDK-Ports (z.B.
|
|
|
Die volle Version des JDK Ports (z.B.
|
|
|
Das vom JDK-Port benutzte Betriebssystem (z.B.
|
|
|
Der Anbieter des JDK-Ports (z.B.
|
|
|
Beschreibung des vom JDK-Port benutzten Betriebssystems (z.B.
|
|
|
Beschreibung des Anbieters des JDK-Ports (z.B.
|
|
|
Pfad zum Installationsverzeichnis des JDK (z.B. '/usr/local/diablo-jdk1.6.0' ). |
|
|
Pfad zum Java-Compiler, der benutzt werden soll (z.B. '/usr/local/diablo-jdk1.6.0/bin/javac' . |
|
|
Pfad zum
|
|
|
Pfad zum
|
|
|
Pfad zur
|
|
|
Pfad zum
|
|
|
Pfad zum
|
|
|
Pfad zum
|
|
|
Pfad zum
|
|
|
Pfad zum
|
|
|
Pfad zum
|
|
|
Pfad zum
|
|
|
Pfad zum RMI Stub/Skeleton-Generator,
|
|
|
Pfad zum RMI Registry-Werkzeug,
|
|
|
Pfad zum RMI Daemon
|
|
|
Pfad zum Archiv, das die JDK-Klassendateien enthält, ${JAVA_HOME}/jre/lib/rt.jar . |
Sie können das
java-debug
make-Target benutzen, um Information zum Debuggen Ihres Ports zu erhalten. Es wird die Werte vieler der obenangegebenen Variablen anzeigen.
Zusätzlich sind die folgenden Konstanten definiert, damit alle Java-Ports auf eine konsistente Art installiert werden können:
| Konstante | Wert |
|---|---|
|
|
Das Basis-Verzeichnis für alles, was mit Java zusammenhängt. Standardmäßig ${PREFIX}/shared/java . |
|
|
Das Verzeichnis, wohin JAR-Dateien installiert werden sollen. Standardmäßig ${JAVASHAREDIR}/classes . |
|
|
Das Verzeichnis, in dem JAR-Dateien, die von anderen Ports installiert wurden, liegen. Standardmäßig ${LOCALBASE}/shared/java/classes . |
Die entsprechenden Einträge sind sowohl in
PLIST_SUB
(dokumentiert in
Änderungen an pkg-plist mit Hilfe von make-Variablen
) als auch in
SUB_LIST
definiert.
Wenn der Port mit Apache Ant kompiliert werden soll, muss er
USE_ANT
setzen. Ant wird dann als das sub-make-Kommando betrachtet. Wenn kein
do-build
-Target vom Port definiert ist, wird eine Standardvorgabe benutzt, die einfach Ant entsprechend
MAKE_ENV
,
MAKE_ARGS
und
ALL_TARGET
aufruft. Das ähnelt dem
USE_GMAKE
-Mechanismus, der in
Build-Mechanismen
dokumentiert ist.
Wenn Sie eine Java-Bibliothek portieren, sollte Ihr Port die JAR-Datei(en) in ${JAVAJARDIR} installieren, und alles andere unter ${JAVASHAREDIR}/${PORTNAME} (ausgenommen die Dokumentation - siehe unten). Um die Größe der Packlistendatei zu reduzieren, können die JAR-Datei(en) direkt im Makefile angegeben werden. Benutzen Sie einfach die folgende Anweisung (wobei myport.jar der Name der JAR-Datei ist, die als Teil des Ports installiert wird):
PLIST_FILES+= %%JAVAJARDIR%%/myport.jar
Beim Portieren einer Java-Applikation installiert der Port normalerweise alles unter einem einzigen Verzeichnis (inklusive seiner JAR-Abhängigkeiten). Die Benutzung von ${JAVASHAREDIR}/${PORTNAME} wird in dieser Beziehung dringend empfohlen. Es liegt im Entscheidungsbereich des Portierenden, ob der Port die zusätzlichen JAR-Abhängigkeiten unter diesem Verzeichnis installieren oder direkt die schon installierten (aus ${JAVAJARDIR} ) benutzen soll.
Unabhängig von der Art Ihres Ports (Bibliothek oder Applikation), sollte die zusätzliche Dokumentation an die
gleiche Stelle
installiert werden wie bei jedem anderen Port auch. Das JavaDoc-Werkzeug ist dafür bekannt einen unterschiedlichen Satz von Dateien abhängig von der Version des benutzten JDKs zu erstellen. Für Ports, die nicht die Benutzung eines bestimmten JDKs vorgeben, ist es deshalb eine komplexe Aufgabe die Packliste (
pkg-plist
) festzulegen. Dies ist ein Grund, warum dringend angeraten wird, das
PORTDOCS
-Makro zu benutzen. Außerdem, selbst wenn Sie den Satz von Dateien, den
javadoc
erzeugen wird, voraussagen können, die Größe der resultierenden
pkg-plist
befürwortet die Benutzung von
PORTDOCS
.
Der Vorgabewert für
DATADIR
ist
${PREFIX}/shared/${PORTNAME}
. Es ist eine gute Idee,
DATADIR
für Java-Ports stattdessen auf
${JAVASHAREDIR}/${PORTNAME}
zu setzen. In der Tat wird
DATADIR
automatisch zu
PLIST_SUB
(dokumentiert in
Änderungen an pkg-plist mit Hilfe von make-Variablen
) hinzugefügt, d.h. Sie können
%%DATADIR%%
direkt in
pkg-plist
benutzen.
Zu der Frage, ob Java-Ports aus dem Quelltext gebaut werden, oder direkt bereitgestellte binäre Distributionen benutzt werden sollten, gab es, als dies geschrieben wurde, keine definierte Richtlinie. Allerdings ermutigen Mitglieder des FreeBSD Java-Projekts Porter dazu, Ihre Ports aus dem Quelltext kompilieren zu lassen, wann immer dies kein Problem darstellt.
Alle Eigenschaften, die in diesem Abschnitt präsentiert wurden sind in bsd.java.mk implementiert. Sollten Sie jemals der Meinung sein, dass Ihr Port ausgefeiltere Java-Unterstützung benötigt, schauen Sie bitte erst in das bsd.java.mk CVS Log , weil es normalerweise immer etwas Zeit braucht bis die neuesten Eigenschaften dokumentiert sind. Wenn Sie glauben, dass der fehlende Support auch für viele andere Java Ports nützlich sein könnte, wenden Sie sich bitte an die freebsd-java.
Obwohl es eine
java
-Kategorie für Fehlerberichte gibt, bezieht sich diese auf die JDK-Portierungsbemühungen des FreeBSD Java-Projektes. Deshalb sollten Sie Ihren Java-Port in der
ports
-Kategorie einreichen wie bei jeden anderen Port auch - es sei denn, die Angelegenheit, die Sie zu klären versuchen, steht in Zusammenhang entweder mit einer JDK-Implementierung oder
bsd.java.mk
.
Gleichermaßen gibt es eine definierte Richtlinie für die
CATEGORIES
eines Java-Ports, die in
Kategorisierung
erklärt wird.
|
|
Der Port benötigt Apache. Mögliche Werte:
|
|
|
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. |
|
|
Vollständiger Pfad zu der
|
|
|
Vollständiger Pfad zu der
|
|
|
Beinhaltet die Versionsnummer des aktuell installierten Apache (nur lesbare Variable). Diese Variable ist nach Einbinden der Datei
bsd.port.pre.mk
verfügbar. Mögliche Werte:
|
|
|
Verzeichnis der Apache-Module. Diese Variable wird automatisch in pkg-plist ersetzt. |
|
|
Verzeichnis der Apache Header-Dateien. Diese Variable wird automatisch in pkg-plist ersetzt. |
|
|
Verzeichnis der Apache-Konfigurationsdateien. Diese Variable wird automatisch in pkg-plist ersetzt. |
|
|
Name des Moduls. Standardwert ist
|
|
|
Der gekürzte Name des Moduls. Standardmäßig wird der Wert von
|
|
|
Verwende
|
|
|
Eine pkg-plist wird automatisch erzeugt. |
|
|
Verzeichnis für zusätzliche Header-Dateien, die beim Kompilieren mitverwendet werden. |
|
|
Verzeichnis für zusätzliche Bibliothek-Dateien, welche beim Kompilieren mitverwendet werden. |
|
|
Zusätzliche Flags für
|
Webanwendungen sollten nach
PREFIX/www/programmname
installiert werden. Der Einfachheit halber ist dieser Pfad sowohl im
Makefile
als auch in
pkg-plist
als
WWWDIR
verfügbar. Der relative Pfad
PREFIX
ist hingegen im
Makefile
durch die Variable
WWWDIR_REL
festgelegt.
Der Benutzername und die Benutzergruppe, mit deren Rechte Webanwendungen laufen, sind in
WWWOWN
und
WWWGRP
festgelegt. Standardwert ist bei beiden
www
. Falls ein Port mit anderen Rechten gestartet werden soll, so sollte die Anweisung
WWWOWN?= myuser
verwendet werden. Dies vereinfacht dem Benutzer eine Anpassung dieser Werte.
Falls die Webanwendung nicht explizit Apache benötigt, so sollte dieser auch nicht als Abhängigkeit des Ports aufgeführt werden. Dadurch bleibt es dem Benutzer überlassen Apache oder einen anderen Webserver zu verwenden.
|
|
Der Port benötigt PHP. Der Wert
|
|
|
Legt die Version von PHP fest, die standardmäßig installiert wird, falls noch kein PHP vorhanden ist. Standardwert ist
|
|
|
Der Port funktioniert nicht mit der angegebenen Version von PHP. Mögliche Werte:
|
|
|
Der Port wird als PHP-Erweiterung gebaut. |
|
|
Der Port wird wie eine PHP-Erweiterung behandelt - Installation und Eintragung in die PHP-Registry für Erweiterungen. |
|
|
Setzt PHP als build-Anhängigkeit. |
|
|
Benötigt die Kommandozeilen-Version von PHP. |
|
|
Benötigt die CGI-Version von PHP. |
|
|
Benötigt das Apache-Modul von PHP. |
|
|
Benötigt die Kommandozeilen- oder die CGI-Version von PHP. |
|
|
Benötigt das Apache-Modul oder die CGI-Version von PHP. |
Das Portieren von PEAR-Modulen ist sehr einfach.
Mit Hilfe der Variablen
FILES
,
TESTS
,
DATA
,
SQLS
,
SCRIPTFILES
,
DOCS
und
EXAMPLES
können die zu installierenden Dateien angegeben werden. Alle aufgeführten Dateien werden automatisch in die jeweiligen Verzeichnisse installiert und der Datei
pkg-plist
hinzugefügt.
Die Datei ${PORTSDIR}/devel/pear/bsd.pear.mk muss am Ende des Makefile s eingebunden werden.
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>
Die Ports unterstützen parallele Installationen mehrerer Python-Versionen. Ports sollten sicherstellen, dass der richtige
python
-Interpreter verwendet wird - entsprechend der durch den Benutzer definierbaren Variable
PYTHON_VERSION
. Häufig bedeutet dies, dass der Pfad zum
python
-Interpreter durch den Wert der Variablen
PYTHON_CMD
ersetzt werden muss.
Ports, die Dateien unter
PYTHON_SITELIBDIR
installieren, sollten
pyXY-
als Präfix des Paketnamens haben, sodass in deren Paketname die zugehörige Python Version aufgeführt wird.
PKGNAMEPREFIX= ${PYTHON_PKGNAMEPREFIX}
|
|
Der Port benötigt Python. Die minimal benötigte Version kann durch Werte wie
|
|
|
Verwende Python-distutils zum Konfigurieren, Kompilieren und Installieren. Dies ist erforderlich, falls der Port eine
setup.py
-Datei beinhaltet. Dadurch werden die
|
|
|
Wird als
|
|
|
Verzeichnis des site-Pakete Baums, der das Installationsverzeichnis von Python (üblicherweise
|
|
|
Die präfix-freie Variante von
|
|
|
Kommandozeilen-Interpreter für Python mit Versionsnummer. |
|
|
Liste der Abhängigkeiten für numerische Erweiterungen. |
|
|
Liste der Abhängigkeiten für die neue numerische Erweiterung numpy. (
|
|
|
Liste der Abhängigkeiten für XML-Erweiterungen (wird ab Python 2.0 nicht mehr benötigt, da im Basispaket enthalten). |
|
|
Setzt die Abhängigkeit des Ports von twistedCore. Die Liste der erforderlichen Komponenten kann als Wert spezifiziert werden. Beispiel:
|
|
|
Setzt Zope, eine Plattform für Webanwendungen, als Abhängigkeit des Ports. Setzt die Versionsabhängigkeit von Python auf 2.3. Setzt
|
Eine vollständige Liste aller verfügbaren Variablen ist in /usr/ports/Mk/bsd.python.mk zu finden.
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.
|
|
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
|
|
|
Der Port benötigt Tcl nur während der Zeit, in der er gebaut wird. |
|
|
Ports, welche zwar die Tcl-Shell, aber nicht eine bestimmte Version von
|
|
|
Benutzerdefinierte Variable, welche die gewünschte Tcl-Version bestimmt. |
|
|
Gleich wie
|
|
|
Fordere threadfähiges Tcl/Tk. |
|
|
Der Port benötigt die Tk-Bibliothek (nicht die Wish-Shell). Impliziert
|
|
|
Analog zur Variable
|
|
|
Analog zur Variable
|
|
|
Analog zur Variable
|
Eine vollständige Liste der zur Verfügung stehenden Variablen befindet sich in /usr/ports/Mk/bsd.tcl.mk .
| Variable | Description |
|---|---|
|
|
Der Port benötigt Ruby. |
|
|
Der Port verwendet extconf.rb für die Konfiguration. |
|
|
Der Port verwendet setup.rb für die Konfiguration. |
|
|
Legt den alternativen Namen von setup.rb fest. Üblich ist der Wert install.rb . |
Die folgende Tabelle listet ausgewählte Variablen auf, die Portautoren über die Port-Infrastruktur zur Verfügung stehen. Diese Variablen sollten für die Installation von Dateien in die entsprechenden Verzeichnisse verwendet werden. Sie sollten in pkg-plist so häufig wie möglich verwendet und in einem Port nicht neu definiert werden.
| Variable | Beschreibung | Beispiel |
|---|---|---|
|
|
Wird als
|
|
|
|
Vollständige Version von Ruby in der Form
|
|
|
|
Installationsverzeichnis der von der Rechnerarchitektur unabhängigen Bibliotheken. |
|
|
|
Installationsverzeichnis der von der Rechnerarchitektur abhängigen Bibliotheken. |
|
|
|
Installationsverzeichnis für die Dokumentation der Module. |
|
|
|
Installationsverzeichnis für die Beispiele der Module. |
|
Eine vollständige Liste der verfügbarenVariablen kann in /usr/ports/Mk/bsd.ruby.mk eingesehen werden.
Die Variable
USE_SDL
wird für die automatische Konfiguration der Abhängigkeiten für Ports benutzt, die auf SDL basierende Bibliotheken wie
devel/sdl12
und
x11-toolkits/sdl_gui
verwenden.
Die folgenden SDL-Bibliotheken sind derzeit bekannt:
sdl: devel/sdl12
gfx: graphics/sdl_gfx
gui: x11-toolkits/sdl_gui
image: graphics/sdl_image
ldbad: devel/sdl_ldbad
mixer: audio/sdl_mixer
mm: devel/sdlmm
net: net/sdl_net
sound: audio/sdl_sound
ttf: graphics/sdl_ttf
Falls ein Port z.B. von net/sdl_net und audio/sdl_mixer abhängt, so wäre die Syntax:
USE_SDL= net mixer
Die Abhängigkeit von devel/sdl12 , die durch net/sdl_net und audio/sdl_mixer entsteht, wird automatisch zum Port hinzugefügt.
Falls
USE_SDL
im Port verwendet wird, so wird automatisch:
die Abhängigkeit von sdl12-config zu
BUILD_DEPENDS
hinzugefügt
die Variable
SDL_CONFIG
zu
CONFIGURE_ENV
hinzugefügt
die Abhängigkeit der ausgewählten Bibliotheken zu
LIB_DEPENDS
hinzugefügt
Um zu überprüfen, ob die SDL-Bibliotheken verfügbar sind, kann die Variable
WANT_SDL
verwendet werden:
WANT_SDL=yes
.include <bsd.port.pre.mk>
.if ${HAVE_SDL:Mmixer}!=""
USE_SDL+= mixer
.endif
.include <bsd.port.post.mk>
Dieser Abschnitt beschreibt den Status der wxWidgets-Bibliotheken in den Ports und deren Einbindung in das Ports-System.
Es gibt viele Probleme bei der gleichzeitigen Verwendung unterschiedlicher Versionen von wxWidgets-Bibliotheken (Dateien unterschiedlicher wxWidgets-Versionen haben denselben Dateinamen). In den Ports wurde das Problem dadurch gelöst, dass jede Version unter einem eigenen Namen installiert wird, der die Versionsnummer als Suffix beinhaltet.
Der offensichtliche Nachteil dabei ist, dass jede Anwendung so verändert werden muss, dass sie die erwartete Version vorfindet. Die meisten solcher Anwendungen benutzen das
wx-config
-Skript, um die benötigten Compiler- und Linkerflags zu erhalten. Dieses Skript hat für jede verfügbare Version einen anderen Namen. Die meisten Anwendungen beachten eine Umgebungsvariable oder ein Argument beim
configure
-Skript, um das gewünschte
wx-config
-Skript festzulegen. Ansonsten müssen sie gepatcht werden.
Um festzulegen, welche Version der wxWidgets verwendet werden soll, gibt es zwei Variablen (falls nur eine der beiden definiert wird, so wird die andere auf einen Standardwert gesetzt):
| Variable | Beschreibung | Standardwert |
|---|---|---|
|
|
Liste der Versionen, die der Port verwenden kann |
Alle verfügbaren Versionen |
|
|
Liste der Versionen, die der Port nicht verwenden kann |
Nichts |
Es folgt eine Liste an möglichen wxWidgets-Versionen und deren zugehöriger Port:
| Version | Port |
|---|---|
|
|
|
|
|
|
|
|
|
Ab Version
|
Die Variablen in Variablen, um die wxWidgets-Version festzulegen können auf einen oder mehrere (durch Leerzeichen getrennt) der folgenden Werte gesetzt werden:
| Beschreibung | Beispiel |
|---|---|
|
Einzelne Version |
|
|
Aufsteigende Versionsnummern |
|
|
Absteigende Versionsnummern |
|
|
Versionsinterval (muss aufsteigend sein) |
|
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.
| Name | Bestimmt für |
|---|---|
|
|
den Port |
|
|
den Benutzer |
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:
| Name | Beschreibung | Versionsbeschränkungen |
|---|---|---|
|
|
Hauptbibliothek |
|
|
|
Beigesteuerte Bibliothek |
|
|
|
wxPython (Python-Bindungen) |
|
|
|
wxMozilla |
|
|
|
wxSVG |
|
Der Typ der Abhängigkeit kann für jede Komponente durch hinzufügen eines Suffix (durch Strichpunkt getrennt) festgelegt werden. Falls der Typ nicht angegeben wird, wird ein Standardwert verwendet (siehe Standardtypen der wxWidgets-Abhängigkeiten ). Die folgenden Typen sind verfügbar:
| Name | Beschreibung |
|---|---|
|
|
Komponente wird zum Bau benötigt - äquivalent zu
|
|
|
Komponente wird zum Ausführen benötigt - äquivalent zu
|
|
|
Komponente wird zum Bau und Ausführen benötigt - äquivalent zu
|
Die Standardwerte für die einzelnen Komponenten sind in der folgenden Tabelle aufgeführt:
| Komponente | Typ der Abhängigkeit |
|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Der folgende Ausschnitt entspricht einem Port, der die wxWidgets-Version
2.4
und die zugehörigen Bibliotheken verwendet.
USE_WX= 2.4 WX_COMPS= wx contrib
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:
| Variable | Beschreibung | Bestimmt für |
|---|---|---|
|
|
Der Port funktioniert ausschließlich mit der Unicode-Version |
den Port |
|
|
Der Port funktioniert in beiden Versionen - bevorzugt wird jedoch Unicode |
den Port |
|
|
Der Port verwendet die Unicode-Version |
den Benutzer |
|
|
Der Port verwendet, falls unterstützt, die normale Version (falls
|
den Benutzer |
|
Die Variable
|
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.
Der folgende Ausschnitt kann in einem Port verwendet werden, der wxWidgets verwendet, falls es installiert ist, oder falls eine Option dafür ausgewählt wurde.
WANT_WX= yes
.include <bsd.port.pre.mk>
.if defined(WITH_WX) || ${HAVE_WX:Mwx-2.4} != ""
USE_WX= 2.4
CONFIGURE_ARGS+=--enable-wx
.endif
Der folgende Ausschnitt kann verwendet werden, um die Unterstützung für wxPython zusätzlich zu der von wxWidgets zu aktivieren (beide in Version
2.6
), wenn das installiert ist, oder die Option ausgewählt wurde.
USE_WX= 2.6
WX_COMPS= wx
WANT_WX= 2.6
.include <bsd.port.pre.mk>
.if defined(WITH_WXPYTHON) || ${HAVE_WX:Mpython} != ""
WX_COMPS+= python
CONFIGURE_ARGS+=--enable-wxpython
.endif
Die folgenden Variablen sind in den Ports verfügbar (nachdem sie entsprechend Variablen, um die wxWidgets-Version festzulegen definiert wurden).
| Name | Beschreibung |
|---|---|
|
|
Pfad zum wxWidgets
|
|
|
Pfad zum wxWidgets
|
|
|
Version der wxWidgets, die verwendet werden soll (z.B.
|
|
|
Falls Unterstützung für Unicode nicht explizit definiert, jedoch verwendet wird, dann wird die Unterstützung automatisch aktiviert. |
Falls die Variablen gleich nach dem Importieren von
bsd.port.pre.mk
benutzt werden sollen, so muss die Variable
WX_PREMK
definiert werden.
|
Falls
|
Der folgende Ausschnitt zeigt die Verwendung von
WX_PREMK
durch Ausführen des
wx-config
-Skriptes, um die vollständige Version als Zeichenkette zu erhalten, diese dann einer Variablen zuzuweisen und die Variable anschließend einem Programm zu übergeben.
USE_WX= 2.4
WX_PREMK= yes
.include <bsd.port.pre.mk>
.if exists(${WX_CONFIG})
VER_STR!= ${WX_CONFIG} --release
PLIST_SUB+= VERSION="${VER_STR}"
.endif
|
Die wxWidgets-Variablen können problemlos in Kommandos benutzt werden, falls diese in Targets ohne gesetztes
|
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.
| Möglicher Wert | Resultierendes Argument |
|---|---|
|
|
|
|
|
|
Dieser Abschnitt beschreibt den Status der Lua-Bibliotheken in den Ports und deren Einbindung in das Ports System.
Es gibt viele Probleme bei der gleichzeitigen Verwendung unterschiedlicher Versionen von Lua-Bibliotheken (Dateien unterschiedlicher Versionen haben denselben Dateinamen). In den Ports wurde das Problem gelöst, indem jede Version unter einem eigenen Namen mit der Versionsnummer als Suffix installiert wird.
Der offensichtliche Nachteil dabei ist, dass jede Anwendung so verändert werden muss, dass sie die erwartete Version vorfindet. Dies kann jedoch durch zusätzliche Flags für Compiler und Linker gelöst werden.
Um festzulegen, welche Version von Lua verwendet werden soll, gibt es zwei Variablen (falls nur eine der beiden definiert ist, so wird die andere auf einen Standardwert gesetzt):
| Variable | Beschreibung | Standardwert |
|---|---|---|
|
|
Liste der Versionen, welche der Port verwenden kann |
Alle verfügbaren Versionen |
|
|
Liste der Versionen, die der Port nicht verwenden kann |
Nichts |
Es folgt eine Liste an möglichen Lua-Versionen und deren zugehöriger Port:
| Version | Port |
|---|---|
|
|
|
|
|
|
|
|
Die Variablen in Variablen, um die Lua-Version festzulegen können auf einen oder mehrere (durch Leerzeichen getrennt) der folgenden Werte gesetzt werden:
| Beschreibung | Beispiel |
|---|---|
|
Spezielle Version |
|
|
Aufsteigende Versionen |
|
|
Absteigende Versionen |
|
|
Versionenintervall (muss aufsteigend sein) |
|
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.
| Name | Bestimmt für |
|---|---|
|
|
den Port |
|
|
den Benutzer |
Der folgende Ausschnitt entspricht einem Port, der Lua in den Versionen
5.0
oder
5.1
verwenden kann und standardmäßig
5.0
verwendet. Diese Einstellung kann durch die benutzerdefinierte Variable
WITH_LUA_VER
überschrieben werden.
USE_LUA= 5.0-5.1 WANT_LUA_VER= 5.0
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:
| Name | Beschreibung | Versionseinschränkungen |
|---|---|---|
|
|
Hauptbibliothek |
Keine |
|
|
Bibliothek für die Unterstützung von C/C++-Code |
|
|
|
Ruby-Bindungen |
|
|
Es gibt weitere Komponenten, die jedoch Module für den Interpreter sind und nicht von Anwendungen benutzt werden (nur von anderen Modulen). |
Der Typ der Abhängigkeit kann für jede Komponente durch Hinzufügen eines Suffix (durch Strichpunkt getrennt) festgelegt werden. Falls der Typ nicht angegeben wird, wird ein Standardwert verwendet (siehe Standardtypen für Lua-Abhängigkeiten ). Die folgenden Typen sind verfügbar:
| Name | Beschreibung |
|---|---|
|
|
Komponente wird zum Bau benötigt - äquivalent zu
|
|
|
Komponente wird zum Ausführen benötigt - äquivalent zu
|
|
|
Komponente wird zum Bau und zum Ausführen benötigt - äquivalent zu
|
Die Standardwerte für die einzelnen Komponenten sind in der folgenden Tabelle aufgeführt:
| Komponente | Typ der Abhängigkeit |
|---|---|
|
|
|
|
|
|
|
|
|
Der folgende Ausschnitt entspricht einem Port, welcher die Lua-Version
4.0
und die zugehörigen Ruby-Bindungen verwendet.
USE_LUA= 4.0 LUA_COMPS= lua ruby
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.
Der folgende Ausschnitt kann in einem Port verwendet werden, der Lua benutzt, falls es installiert ist oder eine Option dafür ausgewählt wurde.
WANT_LUA= yes
.include <bsd.port.pre.mk>
.if defined(WITH_LUA5) || ${HAVE_LUA:Mlua-5.[01]} != ""
USE_LUA= 5.0-5.1
CONFIGURE_ARGS+=--enable-lua5
.endif
Der folgende Ausschnitt kann verwendet werden, um die Unterstützung für tolua zusätzlich zu der von Lua zu aktivieren (beide in Version 4.0), wenn dies installiert ist oder die Option ausgewählt wurde.
USE_LUA= 4.0
LUA_COMPS= lua
WANT_LUA= 4.0
.include <bsd.port.pre.mk>
.if defined(WITH_TOLUA) || ${HAVE_LUA:Mtolua} != ""
LUA_COMPS+= tolua
CONFIGURE_ARGS+=--enable-tolua
.endif
Die folgenden Variablen sind in den Ports verfügbar (nachdem sie entsprechend Variablen, um die Lua-Version festzulegen definiert wurden).
| Name | Beschreibung |
|---|---|
|
|
Die Lua-Version, die verwendet wird (z.B.
|
|
|
Die Hauptversion für shared-Lua-Bibliotheken (z.B.
|
|
|
Die Lua-Version ohne die Punkte (z.B.
|
|
|
Der Präfix, unter dem Lua (und Komponenten) installiert ist |
|
|
Das Verzeichnis unter ${PREFIX}/bin , ${PREFIX}/share und ${PREFIX}/lib , in welchem Lua installiert ist |
|
|
Das Verzeichnis, in dem Lua- und tolua-Header-Dateien installiert sind |
|
|
Das Verzeichnis, in dem Lua- und tolua-Bibliotheken installiert sind |
|
|
Das Verzeichnis, in dem Lua Modul-Bibliotheken ( .so ) installiert sind |
|
|
Das Verzeichnis, in dem Lua-Module ( .lua ) installiert sind |
|
|
Der Paketnamen-Präfix, der von Lua-Modulen verwendet wird |
|
|
Das Verzeichnis, in dem der Lua-Interpreter liegt |
|
|
Das Verzeichnis, in dem der Lua-Compiler liegt |
|
|
Das Verzeichnis, in dem das tolua-Programm liegt |
Der folgende Ausschnitt zeigt, wie einem Port, welcher ein configure-Skript verwendet, mitgeteilt werden kann, wo die Lua-Header-Dateien und Bibliotheken liegen.
USE_LUA= 4.0
GNU_CONFIGURE= yes
CONFIGURE_ENV= CPPFLAGS="-I${LUA_INCDIR}" LDFLAGS="-L${LUA_LIBDIR}"
Falls die Variablen gleich nach dem Einbinden von
bsd.port.pre.mk
benutzt werden sollen, so muss die Variable
LUA_PREMK
definiert werden.
|
Falls
|
Der folgende Ausschnitt zeigt die Verwendung von
LUA_PREMK
durch Ausführen des Lua-Interpreters, um die vollständige Version als Zeichenkette zu erhalten, diese dann einer Variablen zuzuweisen und die Variable schließlich einem Programm zu übergeben.
USE_LUA= 5.0
LUA_PREMK= yes
.include <bsd.port.pre.mk>
.if exists(${LUA_CMD})
VER_STR!= ${LUA_CMD} -v
CFLAGS+= -DLUA_VERSION_STRING="${VER_STR}"
.endif
|
Die Lua-Variablen können problemlos in Befehlen benutzt werden, falls diese in Targets ohne gesetztes
|
Die
USE_XFCE
-Variable wird für die automatische Konfiguration der Abhängigkeiten eingesetzt, welche die Xfce-Basisbibliotheken oder Anwendungen wie
x11-toolkits/libxfce4gui
und
x11-wm/xfce4-panel
verwenden.
Die folgenden Xfce-Bibliotheken und -Anwendungen werden derzeit unterstützt:
libexo: x11/libexo
libgui: x11-toolkits/libxfce4gui
libutil: x11/libxfce4util
libmcs: x11/libxfce4mcs
mcsmanager: sysutils/xfce4-mcs-manager
panel: x11-wm/xfce4-panel
thunar: x11-fm/thunar
wm: x11-wm/xfce4-wm
xfdev: 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.
-I${LOCALBASE}/include
-L${LOCALBASE}/lib
wird CPPFLAGS hinzugefügt und ergibt
CONFIGURE_ENV
.
Wenn also ein Port von sysutils/xfce4-mcs-manager abhängt und die speziellen CPPFLAGS in seiner configure-Umgebung verlangt, dann würde die Syntax wie folgt aussehen:
USE_XFCE= mcsmanager configenv
|
|
Vom Port unterstützte Gecko-Backends. Mögliche Werte sind:
|
|
|
Der Port benötigt Firefox, um korrekt zu funktionieren. Mögliche Werte sind:
|
|
|
Um den Port zu bauen, muss Firefox installiert sein. Wird diese Variable gesetzt, wird automatisch auch
|
|
|
Der Port benötigt Seamonkey, um korrekt zu funktionieren. Mögliche Werte sind:
|
|
|
Um den Port zu bauen, muss Seamonkey installiert sein. Wird diese Variable gesetzt, wird automatisch auch
|
|
|
Dieser Port benötigt Thunderbird, um korrekt zu funktionieren. Mögliche Werte sind:
|
|
|
Um den Port zu bauen, muss Thunderbird installiert sein. Wird diese Variable gesetzt, wird automatisch auch
|
Eine komplette Liste aller verfügbaren Variablen finden Sie in der Datei /usr/ports/Mk/bsd.gecko.mk .
| Variable | Bedeutung |
|---|---|
|
|
Falls die Variable auf
|
|
|
Falls die Variable auf
|
|
|
Falls die Variable auf
|
Weitere Informationen zu diesem Thema finden sich in der Datei bsd.database.mk .
rc.d -Skripten werden zum Starten von Diensten während des Systemstarts verwendet und um den Administratoren einen Standardweg zum Anhalten und Starten von Diensten zu bieten. Ports halten sich an dieses systemweite rc.d -Framework. Details zu deren Benutzung können im rc.d Kapitel des Handbuchs nachgelesen werden. Ausführliche Beschreibungen der verfügbaren Befehle stehen in rc(8) und rc.subr(8) . Desweiteren gibt es einen Artikel zu praktischen Aspekten bezüglich rc.d -Skripten.
Ein oder mehrere rc.d -Skripten können installiert werden mittels:
USE_RC_SUBR= doormand
Skripten müssen im Unterverzeichnis
files
abgelegt und jeder Skript-Datei muss ein
.in
-Suffix hinzugefügt werden. Standardmäßige
SUB_LIST
-Ersetzungen werden für diese Dateien unterstützt. Die Verwendung von
%%PREFIX%%
und
%%LOCALBASE%%
wird dringend empfohlen. Näheres zu
SUB_LIST
kann im
zugehörigen Kapitel
nachgelesen werden.
Für FreeBSD-Versionen, die älter als 6.1-RELEASE sind, ist die Integration mittels
rcorder(8)
möglich, indem
USE_RCORDER
anstatt
USE_RC_SUBR
verwendet wird. Die Verwendung dieser Methode ist jedoch nur notwendig, wenn der Port in die Verzeichnisstruktur des Basissystems installiert werden kann oder der Dienst vor den
FILESYSTEMS
-Skripten in
rc.d
des Basissystems gestartet sein muss.
Seit FreeBSD 6.1-RELEASE sind lokale rc.d -Skripten (inklusive der durch Ports installierten) im allgemeinen rcorder(8) des Basissystems.
Beispiel eines einfachen rc.d -Skripts:
#!/bin/sh
# $FreeBSD$
#
# PROVIDE: doormand
# REQUIRE: LOGIN
# KEYWORD: shutdown
#
# Add the following lines to /etc/rc.conf.local or /etc/rc.conf
# to enable this service:
#
# doormand_enable (bool): Set to NO by default.
# Set it to YES to enable doormand.
# doormand_config (path): Set to %%PREFIX%%/etc/doormand/doormand.cf
# by default.
#
. /etc/rc.subr
name="doormand"
rcvar=${name}_enable
command=%%PREFIX%%/sbin/${name}
pidfile=/var/run/${name}.pid
load_rc_config $name
: ${doormand_enable="NO"}
: ${doormand_config="%%PREFIX%%/etc/doormand/doormand.cf"}
command_args="-p $pidfile -f $doormand_config"
run_rc_command "$1"
Solange kein guter Grund dafür besteht, einen Dienst früher starten zu lassen, sollten alle Ports-Skripten
REQUIRE: LOGIN
verwenden. Falls der Port von einem bestimmten Benutzer (außer root) ausgeführt wird, ist dies zwingend.
KEYWORD: shutdown
ist im Skript oben deswegen vorhanden, weil der frei erfundene Beispiel-Port einen Dienst startet und dieser beim Herunterfahren des Systems sauber beendet werden sollte. Startete das Skript keinen persistenten Dienst, wäre dies nicht notwendig.
Für die Wertzuweisung von Variablen sollte "=" anstatt ":=" verwendet werden, da bei Ersterem nur auf einen Standardwert gesetzt wird, wenn die Variable vorher noch nicht gesetzt war, und bei Letzterem dieser gesetzt wird, auch wenn der Wert vorher Null gewesen ist. Ein Benutzer kann durchaus einen Ausdruck wie
doormand_flags=""
in seiner rc.conf.local -Datei stehen haben, und eine Variablenzuweisung mittels ":=" würde in diesem Fall die Benutzerdefinition überschreiben.
|
Es sollten keine weiteren Skripten mit der .sh -Endung hinzugefügt werden. Irgendwann wird es ein Massenumbenennen aller Skripten im Repository geben, die immer noch diese Endung haben. |
Es ist möglich, dass ein Dienst während der Deinstallation automatisch angehalten wird. Es wird empfohlen dieses Verhalten nur zu implementieren, wenn es unbedingt erforderlich ist zuerst den Dienst anzuhalten und dann die Dateien zu entfernen. Normalerweise sollte es dem Administrator überlassen werden, ob ein Dienst durch Deinstallieren angehalten werden soll. Dies betrifft auch den Vorgang des Aktualisierens.
Der Datei pkg-plist sollte eine Zeile wie folgt zugefügt werden:
@stopdaemon doormand
Das Argument muss dabei mit dem Inhalt der
USE_RC_SUBR
-Variablen übereinstimmen.
Manche Ports setzen voraus, dass ein bestimmter Benutzer auf dem System angelegt ist. Wählen Sie in einem solchen Fall eine freie Kennnummer zwischen 50 und 999 aus und tragen Sie diese in ports/UIDs (für Benutzer) oder ports/GIDs (für Gruppen) ein. Stellen Sie dabei sicher, dass Sie keine Kennnummer auswählen, die bereits vom System oder von anderen Ports verwendet wird.
Erstellen Sie bitte eine entsprechende Patch-Datei für diese beiden Dateien, wenn für Ihren Port ein neuer Benutzer oder eine neue Gruppe angelegt werden muss.
Sie können dann die Variablen
USERS
und
GROUPS
im
Makefile
benutzen, um bei der Port-Installation das automatische Anlegen des Benutzers zu veranlassen.
USERS= pulse GROUPS= pulse pulse-access pulse-rt
Die Liste mit den momentan belegten UIDs (GIDs) befindet sich in ports/UIDs ( ports/GIDs ).
Einige Ports (beispielsweise vom Kernel ladbare Module) benötigen die Kernelsourcen, damit sie gebaut werden können. Die folgenden Zeilen beschreiben den korrekten Weg, wie Sie feststellen können, ob der Benutzer die Kernelsourcen installiert hat:
.if !exists(${SRC_BASE}/sys/Makefile)
IGNORE= requires kernel sources to be installed
.endif
Last modified on : 18. Februar 2025 by Fernando Apesteguía