diff options
Diffstat (limited to 'xml/htdocs/doc/nl/eclass-howto.xml')
| -rw-r--r-- | xml/htdocs/doc/nl/eclass-howto.xml | 1052 |
1 files changed, 0 insertions, 1052 deletions
diff --git a/xml/htdocs/doc/nl/eclass-howto.xml b/xml/htdocs/doc/nl/eclass-howto.xml deleted file mode 100644 index 5e31cc96fa..0000000000 --- a/xml/htdocs/doc/nl/eclass-howto.xml +++ /dev/null @@ -1,1052 +0,0 @@ -<?xml version="1.0" encoding="UTF-8"?> -<!DOCTYPE guide SYSTEM "/dtd/guide.dtd"> -<!-- - Sync: 1.9 ---> - -<guide link = "/doc/nl/eclass-howto.xml"> - -<title>Gentoo Documentation - eclass HOWTO</title> -<author title = "Author"><mail link = "danarmak@gentoo.org" >Dan Armak</mail></author> -<author title = "Editor"><mail link = "zhen@gentoo.org" >John P. Davis</mail></author> -<author title = "Translator"><mail link = "swift@gentoo.org">Sven Vermeulen</mail></author> -<abstract> -De eclass howto legt de basis uit die achter eclasses ligt, alsook de -huidige verzameling eclasses en hoe ze intern werken. Tevens legt dit -document uit hoe je nieuwe eclasses aanmaakt en ebuilds kan overerver. -</abstract> -<version>1.2</version> -<date>28 Juni 2003</date> - -<license/> - -<chapter> -<title>Inleiding tot eclasses</title> - -<section> -<title>Het idee achter eclasses</title> -<body> - -<p> -eclasses zijn modules van gedeelde code. Ze zijn geschreven in bash en -hebben dezelfde syntax als gewone ebuilds, en worden gesourced -(overgeerfd) door ebuilds en andere eclasses om dezelfde instellingen en -functionaliteit aan te bieden doorheen de verschillende ebuilds. -</p> -<p> -Dit wordt gebruikt om maximale code-efficientie en hergebruik te -verkrijgen tussen de verschillende ebuilds. -</p> -<p> -Dit eerste hoofdstuk toont kort hoe je een eclass schrijft die de -standaardtruuks en technieken gebruikt van de bestaande eclasses. Het -tweede hoofdstuk handelt over de KDE eclasses. Het derde hoofdstuk -beschrijft hoe je een KDE ebuild schrijft door gebruik te maken van de -KDE groep eclasses. -</p> - -</body> -</section> - -<section> -<title>Een voorbeeld van een simpele eclass</title> -<body> -<p> -Hieronder vind je een fictieve sourceforge.eclass, gemaakt om de -homepagina en downloadlocaties van een sourceforge-gehost project te -bevatten: -</p> -<pre caption = "Voorbeeld: sourceforge.eclass"> -# Copyright 2003 Gentoo Technologies, Inc. -# Distributed under the terms of the GNU General Public License, v2 or later -# Author Dan Armak <danarmak@gentoo.org> -# $Header: /var/cvsroot/gentoo/xml/htdocs/doc/nl/eclass-howto.xml,v 1.3 2003/10/10 17:24:05 blubber Exp $ -ECLASS=sourceforge -INHERITED="$INHERITED $ECLASS" -# This eclass sets $HOMEPAGE and $SRC_URI to the standard vaules for -# sourceforge.net - hosted projects. - -HOMEPAGE="http://${PN}.sourceforge.net/" -SRC_URI="http://download.sourceforge.net/${PN}/${P}.tar.gz"</pre> - -<note> -De ECLASS= en INHERITED= regels helpen portage op de afhankelijkheden te -cachen van eclasses; ze moeten in elke eclass gedefinieerd zijn, want -anders zal het mis lopen. $ECLASS wordt ook gebruikt bij -EXPORT_FUNCTIONS(). Deze variabelen kunnen in de toekomst ouderwets -worden en automatisch door inherit() gedefinieerd zijn. -</note> -<p> -De eerste 4 regels zijn velden zoals je ze in alle andere ebuilds kan -vinden. De volgende 2 regels zijn een korte beschrijving van de eclass. -De rest van de code doet het eigenlijke werk - SRC_URI en HOMEPAGE -instellen. -</p> -<p> -De meeste eclasses gaan verder dan gewoonweg definieren van variabelen -en helpfuncties aanbieden; ze bevatten default versies van speciale -ebuild functies (src_unpack, src_compile en zo verder). Alvorens een -default functie in een eclass te schrijven moet je weten dat veel van -deze functies al in ebuild.sh gedefinieerd zijn. Deze worden dan -uitgevoerd wanneer je geen specifieke functie in je ebuild neerschrijft -(zelfs niet via een eclass); de default src_unpack() wordt zeer vaak -gebruikt. Indien je dat nog niet gedaan hebt is het interessant een -kijkje te nemen in de default implementatie van ebuild.sh. -</p> - -<p> -Meer moet je eigenlijk niet weten van het neerschrijven van eclasses. -Steek je nieuwe eclass in <path>$PORTDIR/eclass/</path> en schrijf deze -regel neer in het begin van je ebuild: -</p> -<pre caption ="Hoe een eclass overerven"> -inherit sourceforge</pre> -<p> -De inhoud van de eclass zal gesourced worden op dit punt. Herinner dat -elke variabele of functie die in de eclass staat "overschreven" kan -worden door de versie in de ebuild (maar natuurlijk dan enkel voor die -ebuild), aangezien die na de eclass uitgevoerd wordt. Daarom is het -evident om zoveel mogelijk default instellingen en algemene code in je -eclass te steken als mogelijk. Elke niet-standaard instelling en -modificatie kan dan in de ebuild gestoken worden. -</p> -<p> -Oh, en je kan verschillende eclasses overerven tegelijkertijd door ze -samen te sourcen: -</p> -<pre caption = "Verschillende eclasses overerven"> -inherit eclass1 eclass2 [...]</pre> -<p> -... maar let wel op de volgorde. Herinner je eraan, eclasses kunnen -onderling ook zaken overerven en hun instellingen overschrijven, dus -wees voorzichtig met het gebruiken van meerdere eclasses die elkaar -kunnen beinvloeden. -</p> - -<p> -We gaan nu alle tips en truken van eclass-schrijven overlopen, alvorens -we de bestaande eclasses van portage bekijken. -</p> -</body> -</section> - -<section> -<title>inherit()</title> -<body> -<p> -Deze functie woont in ebuild.sh en behandelt het overerven (sourcen) van -eclasses. Het wordt aangesproken met een lijst van eclass namen die -overgeerfd moeten worden: inherit <eclass1> [eclass2 eclass3 ...]. -</p> -<p> -Naast het werkelijke sourcen van de eclass bestanden stelt het de ECLASS -en INHERITED variabelen in welke gebruikt worden door Portage om eclass -aanpassingstijden te cachen. De INHERITED variabele kan gebruikt worden -in een eclass: het bevat een lijst van eclasses die al gesourced zijn op -het moment van lezen, en dit in volgorde van overerving. Dus een eclass -kan deze variabele gebruiken om te determineren of ze werd gesourced via -een eclass of niet. -</p> -</body> -</section> - -<section> -<title>EXPORT_FUNCTIONS</title> -<body> -<p> -Een goede eclass heeft voorgedefinieerde functies die gebruikt kunnen -worden zonder verdere aanpassing; de ebuild zal dan zeer weinig code -moeten hebben (wat een goede zaak is). Soms doet de eclass functie -echter niet precies wat het moet doen. Je kan dan een nieuwe functie -schrijven in je ebuild, die de oude eclass-functie overschrijft voor die -ebuild. Dit is echter negatief inzake code-herbruikbaarheid. Wat we -echter ook kunnen doen is de code van de eclass uitbreiden. -</p> -<p> -Veronderstel dat je src_compile() wil uitbreiden. Je kan een -src_compile() definitie in je ebuild schrijven, welke enkel de stukken -code bevat die niet in de eclass-functie zitten, waarin je dan de -eclass-functie src_compile() zelf aanroept. -</p> -<p> -Indien je echter een nieuwe functie src_compile() aanmaakt zal bash de -oudere functie vergeten waardoor je die niet meer kan aanspreken :( -Daarom bestaat de EXPORT_FUNCTIONS macro. -</p> - -<p> -Laten we een kijkje nemen naar een ander probleem. Veronderstel dat -foo.eclass en bar.eclass beide src_compile() aanbieden. Indien je van -beide de functie overerft zal je een verschillende functie src_compile() -krijgen afhankelijk van de volgorde waarin je de eclasses sourcede. Dat -is normaal, het is de bedoeling dat je zelf weet in welke volgorde -eclasses overgeerfd moeten worden. Maar soms wil je beide src_compile() -functies kunnen aanroepen. -</p> -<p> -Daarom zal elke eclass de functie op zich voor laten gaan met een -prefix. Bijvoorbeeld zal foo.eclass de functie foo_src_compile() laten -heten, en bar.eclass bar_src_compile(). Op die manier kan de ebuild -beide functies aanroepen ongacht de volgorde van overerving. -</p> -<p> -Je wil echter tevens een default functie src_compile() hebben, want -anders zal de ebuild er een moeten definieren. De EXPORT_FUNCTIONS macro -lost zowel dit als voorgaand probleem op. -</p> - -<pre caption = "EXPORT_FUNCTIONS() (van ebuild.sh)">EXPORT_FUNCTIONS() { -while [ "$1" ]; do -eval "$1() { ${ECLASS}_$1 ; }" > /dev/null -shift -done -}</pre> - -<p> -De inherit() functie stelt $ECLASS in op de naam van de eclass alvorens -hij de eclass zelf sourcet. De eclass op zich zal op het einde de macro -EXPORT_FUNCTIONS() aanroepen, samen met een lijst van default functies -die de eclass zelf aanbiedt. Bijvoorbeeld: -</p> -<pre>EXPORT_FUNCTIONS src_compile src_install -</pre> -<p> -waarna EXPORT_FUNCTIONS eval() zal oproepen op de volgende string: -</p> -<pre> -src_unpack() { foo_src_compile() ; } -src_compile() { foo_src_compile() ; }</pre> -<p> -De eclass die als laatste overgeerfd werd zal de default src_compile() -definieren, maar beide functies kunnen aangesproken worden indien dat -nodig blijkt. -</p> - -<p> -Je kan tevens de default src_compile() functie uitbreiden door de eclass -functie op te roepen binnenin je eigen functie. Om dit te -bewerkstelligen moet je natuurlijk de volledige functienaam gebruiken: -</p> -<pre caption="Een eclass-functie uitbreiden"> -#in foo.eclass: -foo_src_compile() { -[default code here] -} - -EXPORT_FUNCTIONS src_compile -#end eclass code - -#in an ebuild: -inherit foo - -src_compile() { -[custom code here] -foo_src_compile -[more custom code] -}</pre> - -</body> -</section> - -<section> -<title>Functie secties</title> -<body> -<p> -Soms is het uitbreiden van functies door extra code ervoor en erna uit -te voeren niet voldoende. Wanneer je met lange, complexe functies werkt -wil je vaak dat een deel van je code in het midden van dergelijke -functies uitgevoerd wordt. -</p> -<p> -Functiesecties bieden een grote flexibiliteit hierrond. Ze delen de -functies in in secties en laten je toe code uit te voeren tussen 2 -secties door. -</p> - -<p> -De implementatie is eenvoudig. Laten we als voorbeeld de src_compile() -functie van base.eclass bekijken (deze bestaat niet meer, maar is een -goed voorbeeld :-). Deze ziet er als volgt uit: -</p> -<pre caption = "Voorbeeld van de originele base.eclass"> -base_src_compile() { - ./configure || die - emake || die -}</pre> -<p> -Hier is dezelfde functie, maar onderverdeeld in secties: -</p> -<pre caption = "Dezelfde functie onderverdeeld in secties."> -base_src_compile() { - - [ -z "$1" ] && base_src_compile all - - while [ "$1" ]; do - case $1 in - configure) - ./configure || die;; - make) - emake || die;; - all) - base_src_compile configure make;; - esac - shift - done - -}</pre> - -<p> -De code is onderverdeeld in 2 delen: <i>configure</i> en <i>make</i>. In -ons eenvoudig voorbeeld komen ze overeen met de 2 commandos in de -originele functie. -</p> -<p> -In het centrum van de nieuwe functie is er een -while;case...esac;shift;done blok. Dit blok komt overeen met de -parameters van de functie met de gedefinieerde sectienamen, en voert de -overeenstemmende stukken code uit. -</p> -<p> -Het speciale geval <i>all</i> zal dezelfde functie recursief oproepen -met een lijst van secties in een bepaalde volgorde. Het hangt af van de -auteur om deze lijst te onderhouden. -</p> -<p> -De regel voorgaand op het blok vertelt ons dat een call zonder -parameters gezien moet worden als een call met de enkelvoudige parameter -<i>all</i>. Zoals je kan zien is deze functie zeer recursief. Merk wel -op dat de oproep <i>base_src_compile configure all make</i> ook geldig -is; deze zal <i>base_src_compile configure configure make make</i> -uitvoeren. -</p> - -<p> -In onze ebuild (of eclass) die base.eclass overerft zie je de functie -src_compile welke base_src_compile oproept zonder paramters. Hierdoor -zal base_src_compile als parameter <i>all</i> nemen, zijnde al de -secties. Je kan dit laten zoals het is. Indien je echter de functie wil -uitbreiden kan je een nieuwe src_compile definieren en base_src_compile -oproepen voor elke sectie apart: -</p> -<pre caption = "Sectie-onderverdelingen gebruiken src_compile()"> -src_compile() { - run_my_code1 - base_src_compile configure - run_my_code2 - base_src_compile make - run_my_code3 -}</pre> -<p> -Zoals je kan zien leveren de functie-secties flexibiliteit aangezien je -nu code kan tussenvoegen, alsook code in andere volgorde uitvoeren of -enkel bepaalde secties ervan. Dit zorgt voor een grotere code -herbruikbaarheid. -</p> - -</body> -</section> - -<section> -<title>De debug-print-* functies</title> -<body> - -<p> -Dit zijn nog functies die door ebuild.sh aangeboden worden. Ze voegen -uitvoerfaciliteiten toe aan eclasses die meer informatie bieden, -waardoor je hun uitvoeringen gemakkelijker kan traceren zonder dat je -bash debug mode moet activeren. Alle eclasses zouden deze functies vaak -moeten oproepen. -</p> - -<p> -debug-print() print simpelweg alle parameters met als voorvoegsel -'debug:'. Deze wordt uitgevoerd wanneer er iets interessants in de debug -log gestoken moet worden. -</p> -<p> -debug-print-function() print 'debug: entering function $1, parameters: -$2 [$3 $4 ...]'. Ze wordt aan het begin van een functie uitgevoerd. -</p> -<p> -debug-print-section() print 'debug: now in section $1'. Deze wordt -uitgevoerd aan het begin van een functie's sectie. -</p> - -<p> -De debug output gaat normaal gezien in $T/eclass-debug.log. Je kan de -ECLASS_DEBUG_OUTPUT omgevingsvariabele (in make.globals/conf of in de -omgeving zelf) instellen waardoor de output daarnaartoe zal gestuurd -worden. Je kan tevens die variabele instellen op de speciale variabele -'on' waardoor de uitvoer naar stdout gestuurd wordt samen met de emerge -boodschappen. -</p> - -<p> -Laten we eens wat typische debug uitvoerstatements toevoegen aan onze -voorbeeld functies: -</p> -<pre caption = "debug statements toevoegen"> -base_src_compile() { - - debug-print function $FUNCNAME $* - [ -z "$1" ] && base_src_compile all - - while [ "$1" ]; do - case $1 in - configure) - debug-print-section configure - ./configure || die;; - make) - debug-print-section make - make || die;; - all) - debug-print-section all - base_src_compile configure make;; - esac - shift - done - - debug-print "$FUNCNAME: result is $RESULT" -}</pre> -<p> -Ter informatie, $FUNCNAME is een bash-ingebouwde variabele die de naam -van de huidige functie bevat. -</p> - -</body> -</section> - -<section> -<title>newdepend()</title> -<body> - -<p> -Deze ebuild.sh functie voegt simpelweg alle parameters toe aan zowel -DEPEND als RDEPEND, waardoor je niet alle moeite van het schrijven en -onderhouden van 2 lijsten van afhankelijkheden moet doorgaan. -</p> - -<p> -Indien opgeroepen met een speciale parameter voegt het voorgedefinieerde -afhankelijkheden toe. Ik denk niet dat dit echt elegant is (of toch niet -meer), ik heb liever expliciete afhankelijkheden; dus dit kan je als -ouderwets aanzien :) -</p> -<p> -De volgende speciale parameters zijn beschikbaar: -</p> -<p> -newdepend /autotools: voegt sys-devel/autoconf sys-devel/automake sys-devel/make toe aan DEPEND (maar niet RDEPEND). -</p> -<p>newdepend /c: voegt virtual/glibc sys-devel/ld.so toe aan zowel DEPEND als RDEPEND. Voegt tevens sys-devel/gcc toe aan DEPEND.</p> - -</body> -</section> -</chapter> - -<chapter> -<title>Bestaande eclasses</title> - -<section> -<title>Inleiding</title> -<body> -<p> -De meeste eclasses zijn eenvoudig en je zou ze simpelweg moeten lezen en -mogelijk eens een kijkje nemen naar andere ebuilds om te verstaan hoe ze -werken. Ook zijn de meeste eclasses goed uitgerust van commentaar, zodat -het zeer interessant is deze te lezen. -</p> -<p> -Dit hoofdstuk documenteert de algemene relaties tussen de kde* eclasses. -</p> -</body> -</section> - -<section> -<title>base.eclass</title> -<body> - -<p> -Deze eclass definieert enkele default variabelen en functies, analoog -aan deze die je krijgt als je geen overerving gebruikt (en dus -gedefinieerd zijn in ebuild.sh). Je bent waarschijnlijk niet -geinteresseert deze rechtstreeks te gebruiken, maar eerder via een -andere eclass die ze overerft. -</p> -<p> -Een interessante functionaliteit is dat het de autopatch capabiliteit -aanbiedt. Indien je de PATCHES variabele instelt met een lijst van -bestanden in je ebuild dat base_src_unpack() (of kde_src_unpack()) -gebruikt, dan zullen de broncodebestanden gepatched worden met deze -bestanden. De patches moeten werken met -p0 wanneer ze uitgevoerd worden -vanuit $S. -</p> -<p> -Weet dat je PATCHES kan instellen zonder een eigen src_unpack() te -definieren in je ebuild. Het is vooral daarom dat het zeer interessant -is. -</p> -<p> -De nieuwere epatch() functie van eutils.eclass is heel wat krachtiger - -het ondersteunt gecomprimeerde patches, patch directories en series en -automatiseert de detectie van de patchlevel - en ooit zal autopatch -hiervan gebruik maken :) -</p> -<p> -De <i>patch</i> sectie in base_src_unpack() is ouderwets en zal -binnenkort verwijderd worden. Indien je een ebuild opmerkt die hiervan -gebruik maakt, dan moet het geconverteerd worden om gebruik te maken van -de <i>autopatch</i> stijl. -</p> - -</body> -</section> - -<section> -<title>kde-functions.eclass</title> -<body> - -<p> -Deze eclass bevat alle KDE-gerelateerde hulpfuncties. Sommige hiervan -zal je waarschijnlijk nooit nodig hebben; deze worden hier niet -besproken, maar zijn goed gecommentarieerd in de broncodebestanden. -</p> -<p> -Merk op dat met 'helper functions' ik de functies bedoel die geen -speciale ebuildfuncties zijn (zoals src_unpack()). Alle kde eclasses -met dergelijke 'speciale' functies erven van kde-functions. -</p> -<p> -De enige code buiten deze functies in kde-functions.eclass (welke dus -uitgevoerd wordt tijdens het sourcen) is een blok die kijkt of de -huidige ebuild al dan niet van kde-base is. Indien wel, dan wordt -KDEBASE=true. Deze variabele wordt gebruikt in verschillende tests -waardoor het comfortabel is deze op 1 centrale plaats te definieren. -</p> - -<br/> -<p><b>De huidige multi-kdedir schema</b></p> -<p> -Een korte uitleg over hoe Gentoo de verschillende KDE versies -onderhoudt: -</p> -<p> -De KDEs (zijnde zaken van kde-base) leven in -/usr/kde/${major-version}.${minor-version}. Dus bijvoorbeeld KD 3.1.x -woont in /usr/kde/3.1. Dit schema wordt echter pas gebruikt na versie -3.0 dus oudere versies wonen in niet-standaard locaties: KDE 3.0.x woont -in /usr/kde/3 (en niet in /usr/kde/3.0) en KDE 2.2.2 in /usr/kde/2. De -cvs ebuilds installeren in /usr/kde/cvs. -</p> -<p> -Je kan dus verschillende KDE versies naast elkaar geinstalleerd staan -hebben. kde-base pakketten hebben een SLOT van major.minor (e.g. 3.0 en -3.1). -</p> -<p> -Aangezien QT versies volledig compatible zijn tussen de verschillende -minor-versies hebben we er een van elke major-versie beschikbaar staan -en dit met een verschillende SLOT; deze leven in /usr/qt/$major. -</p> -<p> -Een niet-kde-base ebuild moet zich altijd in /usr installeren. Het -kde-env pakket plaatst KDEDIRS=/usr in env.d waardoor deze programmas -correct functioneren. Dit programma compileert en linkt tegen de laatste -KDE bibliotheekbestanden; de eclass controleert de standaard locaties in -dalende volgorde - /usr/kde/cvs, dan /usr/kde/3.1, dan /usr/kde/3. -(kde-base ebuilds zullen altijd linken tegen de kdelibs van hun eigen -versie). Dit hangt natuurlijk ook af van de parameter die aan need-kde() -gegeven wordt. -</p> - -<p> -Er zijn verschillende speciale variabelen die je kan instellen om de -default instellingen van dit systeem aan te passen. Hun primair gebruik -is om de ebuild te compileren tegen een specifieke KDE die je -geinstalleerd staan hebt om te testen, maar je kan ze tevens gebruiken -om tegen een KDE te compileren die in een niet-standaard locatie staat, -waardoor je bijvoorbeeld KDE 3.0.1 en KDE 3.0.2 kan geinstalleerd staan -hebben. Dit is zeer interessant voor testen en ontwikkeling. -</p> -<p> -Alle KDE applicaties (base en niet-base) installeren in $KDEPREFIX -indien deze ingesteld is. Het heeft voorrang op alle andere zaken in de -eclassen. -</p> -<p> -Een KDE applicatie (zelfs indien het een kde-base is) zal proberen te -linken tegen de kdelibs die in $KDELIBSDIR staan indien ingesteld. -Indien dit niet lukt zal het terugvallen naar de default locaties om de -laatst mogelijke kdelibs te gebruiken. -</p> - -<br/> -<p><b>need-kde(), need-qt(), set-kdedir(), set-qtdir()</b></p> -<p> -kde-functions.eclass biedt 2 paar van functies aan: need-kde(), -need-qt() en set-kdedir(), set-qtdir(). Deze functies behandelen de -details van de verschillende KDEs en QTs installaties. -</p> - -<p> -De need-kde() functie wordt met een parameter opgeroepen die de minimale -versie van kdelibs omschrijft die nodig is. Het zal de correcte -afhankelijkheden aan DEPEND en RDEPEND toevoegen en zal de functie -set-kdedir() oproepen. Indien geen parameter doorgegeven wordt zal een -versienummer van 0 (nul) gebruikt worden, wat wil zeggen dat eender -welke versie aan de afhankelijkheid voldoet. need-kde() roept tevens -need-autoconf() en need-automake() op met de correcte parameters voor de -specifieke KDE versie. -</p> -<p> -De set-kdedir() functie zal dan de installatieprefix vastleggen en de -kdelibsdir locatie instellen die je ebuild zou moeten gebruiken. Deze -worden dan doorgegeven via $PREFIX en $KDEDIR (en worden automatisch -afgehandeld in kde.eclass). Merk op dat geen enkel ebuild $KDEPREFIX en -$KDELIBSDIR direct moet adresseren! -</p> -<p> -need-kde() zoekt tevens de minimale QT-versie op die nodig is voor deze -versie van kdelibs uit een tabel. Het zal dan need-qt() met deze versie -oproepen. Een enkel-qt programma (i.e. niet-kde) zal meestal need-qt() -zelf oproepen zonder gebruik te maken van need-kde(). -</p> - -<p> -De need-qt() functie voegt de vereiste QT-versie toe aan DEPEND en -RDEPEND en roept dan set-qtdir() op met die versie als argument. De -set-qtdir() functie stelt QTDIR in op de default locatie van deze versie -van QT. In tegenstelling tot set-kdedir() zal set-qtdir() niet -controleren of er op die locatie een QT geinstalleerd staat. -</p> - -<p> -need-kde() (of need-qt()) moeten rechtstreeks opgeroepen worden vanuit -de ebuild (en niet vanuit een functie) zodat aanpassingen aan DEPEND en -RDEPEND de emerge-resultaten beinvloeden. -</p> - -<p><b>need-autoconf(), need-automake()</b></p> - -<p> -Deze functies stellen de nodige omgevingsvariabelen in om de vereiste -versie van automake of autoconf uit te voeren. Ze verwijderen tevens -alle voordien ingestelde variabelen die hierop betrekking hebben. -Bijvoorbeeld zal 'need-automake 1.4' NEED_AUTOMAKE_1_4=1 instellen -terwijl alle andere WANT_AUTOMAKE* variabelen verwijderd worden. Voor -meer informatie zie de broncode van de functie en de commentaar in het -begin van /usr/bin/auto{conf,make} (op een Gentoo systeem). -</p> - -<p><b>kde_sandbox_patch()</b></p> -<p> -Sommige KDE makefiles zijn slecht in elkaar gestoken. Ze chmod'en of -chown'en bestanden in PREFIX wanneer ze installeren zonder naar DESTDIR -te kijken. Maw kopieren ze bestanden correct naar -$DESTDIR/$PREFIX/path/foo, maar ze chmod'en dan $PREFIX/path/foo welke -hoogstwaarschijnlijk nog niet eens bestaat. En indien ze bestaat dan -zorgt de sandbox voor een foutmelding. -</p> -<p> -Deze functie voert een algemene sed uit op makefiles welke alle bekende -foutgevende Makefiles herstelt. Ze wordt uitgevoerd met als parameter de -directories die doorzocht moeten worden en ze wordt uitgevoerd op -Makefile, Makefile.am en Makefile.in in die directories. Bijvoorbeeld: -</p> -<pre caption = "kde_sandbox_patch() in werking"> -src_unpack() { - base_src_unpack - kde_sandbox_patch ${S}/dir1 ${S}/dir2/dir3 -}</pre> - -<br/> -<p><b>kde_remove_flag()</b></p> -<p> -Deze wordt gebruikt om compilatievlaggen weg te werken van welke we -weten dat ze pakketten kapot maakt. Je voert deze uit na het uitpakken -en met als parameter de subdirectorie waarin het moet gebeuren, en de -naam van de vlag die verwijderd moet worden. Weet wel dat dit niet -recursief is. Bijvoorbeeld: "kde_remove_flag foodir/barfoo --fomit-frame-pointer". -</p> - -<br/> -<p><b>kde_remove_dir() en $KDE_REMOVE_DIR</b></p> -<p> -Deze functie verwijdert de gegeven subdirectorie uit de compilatie. Het -verwijdert de directorie en alle verwijzingen ernaartoe in het subdirs -bestand, configure en in de makefiles. Weet dat dit enkel werkt op -subdirectories van $S en niet op ander niveau. Je kan ze oproepen met -een lijst van subdirectories; ze wordt dan uitgevoerd op elke -parameters. -</p> -<p> -Je kan ze trouwens rechtstreeks oproepen, maar het is interessanter om -KDE_REMOVE_DIR in te stellen op een lijst van subdirectories die -verwijderd moet worden zodat je geen eigen src_unpack() moet maken. -Zoals je kan zien gaan we zeer ver in het voorkomen van het schrijven -van een eigen functie in een ebuild, wat resulteert in een mooier ogende -ebuild. -</p> - -</body> -</section> - -<section> -<title>kde.eclass</title> -<body> - -<p> -Dit is de hoofd KDE eclass. Ze bevat de meeste KDE-gerelateerde code. -Alle KDE ebuilds erven hiervan op een of andere manier. De KDE eclass -erft van base en kde-functions. -</p> -<p> -Zoals met de meeste eclasses is het het beste om de broncode te lezen om -te zien wat ze uitspookt. Het meeste zou zelfverklarend moeten zijn. -Hier volgt een korte samenvatting: -</p> - -<p> -De eclass's globale sectie (i.e. deze die uitgevoerd wordt wanneer je ze -overerft) voegt de nodige afhankelijkheden toe aan kde-env, automake, -autoconf, make en perl (deze is nodig door de standaard -configuratiescripts voor snelle makefile-generatie). Het stelt tevens de -default SLOT="0". -</p> - -<p> -kde_src_unpack() roept eigenlijk base_src_unpack() op met extra -parameters (met name secties die uitgevoerd moeten worden). Hierna zal -het kde-specifieke zaken toevoegen. Het zal alle .ui bestanden in de -uitgepakte directorie vernieuwen om alle overblijvende .cpp en .h -bestanden te regenereren. Het zal tevens kde_remove_dir() oproepen met -$KDE_REMOVE_DIR indien deze variabele ingesteld is (zie hierboven). -</p> - -<p> -kde_src_compile() bevat tevens verschillende fixen. Een ervan is het -exporteren van kde_widgetdir="$KDDIR/lib/kde3/plugins/designer" om zo de -fout in oudere kde acinclude.md4.in's op te lossen. Een andere bugfix is -het instellen van HOME="$T/fakehome" zodat alle toegangen tot $HOME/.kde -en $HOME/.qt niet door sandbox gestopt worden en dus niet de gebruikers' -homedirectories aantasten. Dit is een bug (of tekortkoming) van uic dat -het altijd probeert om de configuratiebestanden in deze locaties te -lezen. -</p> -<p> -kde_src_compile() heeft verschillende secties. <i>myconf</i> voegt de -default kde configuratiescriptparameters toe aan $myconf, zoals ---prefix=${PREFIX} (herinner, $PREFIX wordt door set-kdedir() -gedefinieerd). Je kan je eigen waarden aan $myconf toevoegen voor of na -deze sectie; overschrijf gewoon nooit de oude waarden, aangezien -gebruikers $myconf willen kunnen instellen op de commandoregel. -</p> -<p> -De <i>configure</i> sectie voert de configure scripts uit in $S en dit -met $myconf als parameters. Indien de configuratiescript niet bestaat -zal het deze proberen aan te maken door make -f Makefile.cvs of make -f -admin/Makefile.common uit te voeren. Dus in deze stage van compilatie -(welke nodig is voor cvs snapshots en ebuilds die bestanden patchen -zoals configure.in) wordt dit allemaal automatisch gedaan. -</p> -<p> -De <i>make</i> sectie voert simpelweg emake || die uit. Uiteindelijk is -er ook hier een <i>all</i> sectie die alle bovenstaande secties omvat. -</p> - -<p> -Uiteindelijk heeft kde_src_install() een <i>make</i> sectie die make -install uitvoert, een <i>dodoc</i> sectie die dodoc uitvoert op -standaard documentnamen in $S, zoals README en COPYING. -</p> - -</body> -</section> - -<section> -<title>kde-base.eclass</title> -<body> - -<p> -Deze eclass ondersteunt de standaard KDE applicaties; bijna alle KDE -ebuilds maken er gebruik van. Op dit moment erft deze enkel van kde, -roept ze newdepend /c op (default afhankelijkheden van glibc en -dergelijke toevoegen) en stelt HOMEPAGE=apps.kde.com in. -</p> -<p> -Dit lijkt niet voldoende reden om een extra eclass te maken, maar in het -verleden heeft het enkele oplossingen van bepaalde fouten bevat die niet -in kde.eclass zaten (aangezien deze ook gebruikt wordt door ebuilds die -geen zaken compileren, zoals de i18n pakketten en artwork). Het kan zijn -dat we deze in de toekomst als verouderd zullen aanzien, maar op dit -moment gebruiken alle standaard kde applicaties het. -</p> - -</body> -</section> - -<section> -<title>kde.org.eclass</title> -<body> - -<p> -Deze eclass wordt gebruikt door de kde-base/ basispakketten, en mogelijk -door andere pakketten die op ftp.kde.org en mirrors gehost worden -(kdevelop, koffice, kdoc). Het stelt de SRC_URIs in en voegt de mirrors -van ftp.kde.org toe. -</p> - -</body> -</section> - - -<section> -<title>kde-dist.eclass</title> -<body> - -<p> -Deze eclass is voor de standaard kde distributiepakketten in kde-base/*. -Ze erft kde-base en kde.org over. -</p> -<p> -Ze stelt de juiste DESCRIPTION en HOMEPAGE in en roept need-kde $PV op. -De eenvoudigere of kleinere kde-base/ pakketten (zoals kdetoys) moeten -geen aanpassingen hieraan maken; de meeste voegen enkel patches en -afhankelijkheden toe. -</p> - -</body> -</section> - - - -<section> -<title>kde-i18n.eclass</title> -<body> - -<p> -Deze eclass is voor de kde-i18n-* pakketten. Eigenlijk zijn alle -kde-i18n pakketten volledig identiek dus moeten ze enkel van deze eclass -overerven. De variabelen $P en $PV doen de rest. -</p> - -</body> -</section> - -<section> -<title>koffice-i18n.eclass</title> -<body> - -<p> -Deze eclass heeft als bedoeling de koffice-i18n-pakketten te -ondersteunen en is zeer gelijkaardig aan kde-i18n.eclass. Opnieuw, alle -kde-i18n ebuilds zijn volledig gelijkaardig dus alles wat ze moeten doen -is van deze eclass overerven. -</p> - -</body> -</section> - -<section> -<title>cvs.eclass</title> -<body> - -<p> -Deze eclass biedt speciale functionaliteit aan om 'live' cvs ebuilds aan -te maken. Dergelijke ebuilds halen de broncode vanuit een CVS server -waardoor altijd de laatste bugs en fixes van de ontwikkelings-stadium -meegenomen worden. -</p> -<p> -De nodige ondersteuning voor live cvs ebuilds (zoals versioning) is nog -niet geintegreerd in Portage. Ze werkt met de eclass, maar het is -onhandig in vele zaken. Denk dus tweemaal na alvorens je een live ebuild -aanmaakt; misschien is een reguliere cvs snapshot interessanter. Indien -je van plan bent dergelijke ebuild aan portage toe te voegen, lees dan -zeker de regels voor live cvs ebuilds uit de ontwikkelings handleiding -van Gentoo. -</p> - -<p> -Alvorens je van cvs.eclass overerft moet je alle niet-default -instellingen instellen (op zijn minst de server en module-naam). Zie ook -de lijst van configureerbare instellingen en default waarden aan het -begin van cvs.eclass, gemarkeerd als 'ebuild-configurable setting'. -</p> -<p> -Hierna gebeurt alles quasi automatisch. Een cvs_src_unpack() (geen -secties) wordt geleverd. Indien je meer wil weten, lees de broncode van -de eclass zelf. -</p> - -</body> -</section> - -<section> -<title>kde-source.eclass</title> -<body> - -<p> -Deze eclass werkt bovenop cvs.eclass, welke extra kde-specifieke -functionaliteit toevoegt. Bijvoorbeeld haalt het vanzelf de admin/ -directorie van de kde-common module af. Lees de eclass om meer te weten -te komen, inclusief kde-cvs-specific instellingen welke je kan -doorgeven. -</p> - -</body> -</section> -</chapter> - -<chapter> -<title>KDE ebuilds schrijven</title> - -<section> -<title>Inleiding</title> -<body> - -<p> -Dit hoofdstuk legt je uit hoe je standaard KDE ebuilds schrijft. Alles -wat hier uitgelegd wordt is eigenlijk niet meer dan een extra -herinnering van alles wat hierboven vermeld werd. Wanneer je twijfelt, -kijk dan naar andere ebuilds/eclasses of vraag het aan ontwikkelaars. -</p> - -</body> -</section> - -<section> -<title>Een typische KDE ebuild</title> -<body> - -<p> -De code hieronder zou heel wat gemakkelijker te lezen zijn na het -doorlopen van deze howto: -</p> -<pre caption = "Een simpele KDE ebuild, #1"> -<header lines> -inherit kde-base</pre> -<p> -Sommige ebuilds stoppen al hier. Anderen hebben meer veranderingen -nodig. -</p> - -<p> -De volgende stap is om extra afhankelijkheden toe te voegen. Herinner je -eraan, breid variabelen altijd uit, stel ze niet gewoon in! -</p> -<p> -Aangezien ons doel is om zoveel mogelijk code te hergebruiken en geen -extra code te schrijven tenzij echt noodzakelijk, stellen we zoveel -mogelijk in via variabelen in de ebuild. Herinner je eraan dat er -limitaties zijn aan de code binnenin de ebuild. Bijvoorbeeld mag het -geen output introduceren (debug-print() output telt niet). -</p> - -<pre caption = "Een eenvoudige KDE ebuild, #2: extra afhankelijkheden toevoegen" > -DEPEND="$DEPEND foo/bar" -RDEPEND="$RDEPEND bar/foo"</pre> - -<p> -Alternatief zal een newdepend() oproep een afhankelijkheid toevoegen aan -DEPEND en RDEPEND: -</p> - -<pre caption = "Een eenvoudige KDE ebuild, #3: newdepend() gebruiken" > -newdepend "foo? ( bar )"</pre> - -<p> -We willen tevens extra argumenten toevoegen aan myconf, welke dan -doorgegeven worden aan configure (in de veronderstelling dat we -kde_src_compile gebruiken): -</p> - -<pre caption = "Een eenvoudige KDE ebuild, #4: argumenten doorgeven aan configure" > -myconf="$myconf --with-foobar"</pre> - -<p> -We hebben tevens enkele patches die we moeten toepassen. Indien ze via --p0 kunnen toegepast worden binnenin $S dan kunnen we base_src_unpack's -<i>autopatch</i> gebruiken. Herinner je eraan dat kde_src_unpack() -base_src_unpack() aanroept met de parameters die je eraan meegeeft: -</p> -<pre caption = "Een eenvoudige KDE ebuild, #5: patches toepassen" > -PATCHES="$FILESDIR/$P-myfix.diff"</pre> - -<p> -Uiteindelijk willen we src_install() uitbreiden om wat extra -documentatie te installeren: -</p> - -<pre caption = "Een eenvoudige KDE ebuild, #6: src_install() uitbreiden" > -src_unpack() { - kde_src_install - dodoc $S/doc/* -}</pre> - -<p> -Laten we nu eens naar de ebuild in zijn geheel kijken: -</p> - -<pre caption = "Een eenvoudige KDE ebuild, helemaal" > -<header lines> -inherit kde-base - -# add deps -DEPEND="$DEPEND foo/bar" -RDEPEND="$RDEPEND bar/foo" -newdepend "foo? ( bar )" - -# always enable foobar -myconf="$myconf --with-foobar" - -# fix terrible bug -PATCHES="$FILESDIR/$P-myfix.diff" - -src_unpack() { - kde_src_install -# install some extra docs not included in make install's targets - dodoc $S/doc/* -}</pre> - -</body> -</section> - -<section> -<title>Een typische ebuild met optionele KDE ondersteuning</title> -<body> - -<p> -Wanneer we kde (eclass) functionaliteit toevoegen aan een bestaande -ebuild moeten we eigenlijk eenvoudigweg elke kde-specifieke regel laten -voorgaan met <c>use kde &&</c> of een volledige <c>if [ -n "`use -kde`" ]; then ...; fi</c> introduceren. -</p> - -<p> -In het hoofdblok zet je het volgende (enkel indien USE kde ingesteld is -natuurlijk): -</p> - -<pre caption = "Optionele KDE ondersteuning -- ebuild sectie" > - inherit kde-functions -# this will add kdelibs, kde-env to your dep strings and set $KDEDIR -# to the correct value: - need-kde $version # minimal version of kde your app needs - -# add anything else you need for kde support: -use kde && myconf="$myconf --with-my-parameter"</pre> - -<p> -Daarna zeg je tegen de applicatie dat hij naar KDE moet zoeken in de -$KDEDIR instelling die beschikbaar is na het oproepen van need-kde(). -Indien je niet wenst om de kdelibs afhankelijkheid toe te voegen moet je -set-kdedir() gebruiken in plaats van need-kde(). -</p> - -</body> -</section> -</chapter> - -</guide> |