Gentoo Documentation - eclass HOWTO

1.Introduzione alle eclasses

L'idea dietro le eclasses 

Le eclasses sono moduli di codice condiviso. Sono scritte in bash e hanno la stessa sintassi degli ebuild ordinari, sono ereditate dagli ebuilds e dalle altre eclasses, per provvedere a dare dei settaggi di default e funzionalità per molti ebuild simili.

Vengono utilizzate per assicurare il miglior riutilizzo di codice possibile per gli ebuild simili.

Questo primo capitolo spiega brevemente come scrivere una eclass includendo i trucchi standard e le tecniche utilizzate nelle eclasses esistenti. Il secondo è uno sguardo d'insieme alle eclasses kde. Il terzo spiega come scrivere un ebuild KDE utilizzando il gruppo delle eclasses kde.

Un esempio di eclass semplice 

Qui abbiamo una eclass sourforge.eclass fittizia, scritta per fornire le locazioni della homepage e del download ai progetti hostati da sourceforge:

# 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/www/www.gentoo.org/raw_cvs/gentoo/xml/htdocs/doc/it/eclass-howto.xml,v 1.4 2004/05/01 15:01:32 mush 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"

Le prime quattro linee sono headers, come quelle in ogni ebuild. Le altre due linee sono una corta descrizione della eclass. Il resto del codice setta SRC_URI e HOMEPAGE.

La maggior parte delle eclasses vanno oltre i settaggi di variabili e la fornitura di funzioni di supporto; esse contengono le versioni di default delle funzioni speciali degli ebuild (src_unpack, scr_compile e così via). Prima di scrivere una funzione di default in una eclass, dovete controllare quella già contenuta in ebuild.sh(se esiste). Essa sarà quella che verrà eseguita se non ne mettete una vostra nell'ebuild (non sempre tramite eclass); la scr_unpack() di default viene spesso usata. Se non la avete ancora, andate a guardare le implementazioni di default in ebuild.sh.

Questo è tutto ciò che avete bisogno di conoscere per scrivere le eclasses. Mettete le vostre eclass in $PORTDIR/eclass/, e mettete questa linea all'inizio del vostro ebuild:

                        inherit sourceforge

I contenuti delle eclass dovranno essere incluse a questo punto. Ricordate che ogni variabile o funzione definita nella eclass può essere sovrascritta da una nell'ebuild, il cui codice viene eseguito con priorità più alta rispetto alle eclasses. Comunque, potete provare a mettere più settaggi di default possibili e codice comune nella eclass. Ogni settaggio non standard e modificazione può quindi venir messa nell'ebuild.

Puoi anche includere varie eclasses nello stesso tempo scrivendo:

                        inherit eclass1 eclass2 [...]

attenzione però al loro ordine! Ricordate, le eclasses possono ereditare una e sovrascrivere i settaggi di un'altra, quindi bisogna stare attenti quando si includono eclasses multiple che possono influenzarne altre.

Possiamo ora andare avanti e vedere i trucchi per la scrittura delle eclass, prima di andare a quelleattuali di portage.

inherit() 

Questa funzione risiede in ebuild.sh e gestisce l'inclusione delle eclasses. Viene chiamata con una lista di nomi di eclass da ereditare: inherit <eclass1> [eclass2 eclass3...].

Inoltre includere i file eclass, setta le variabili ECLASS e INHERITED usate da portage per registrare i timestamp di modifica. La variabile INHERITED si usa scrivendo le eclasses: contiene una lista di tutte le classi ereditate dal punto dove è dichiarata la variabile, in ordine. Ciò fa determinare alla eclass se è stata chiamata da qualche altra eclass.

EXPORT_FUNCTIONS 

Molte funzioni predefinite di eclass possono essere usate come sono; l'ebuild allora conterrà poco codice (che è un'ottima cosa). Talvolta, comunque, le funzioni eclass non fanno esattamente ciò che vi serve. Potete allora scrivere una nuova funzione nell'ebuild, sovrascrivendo la definizione della funzione della eclass. Comunque, questo minimizzerà il beneficio della riutilizzazione di codice. Quindi proviamo ad estendere le funzioni delle eclasses.

Supponiamo di voler estendere src_compile(). Potete scrivere una definizione di scr_compile() nel vostro ebuild che includerà solo le parti mancanti della src_compile() nella eclass. Dovete allora chiamare la eclass src_compile() dal codice della vostra funzione personalizzata.

Ad ogni modo, se create una nuova funzione chiamata src_compile(), bash dimenticherà tutto della vecchia e non potrete chiamarla! E` qui che entrano in gioco le macro EXPORT_FUNCTIONS.

Diamo un'occhiata a un altro problema per un momento. Supponiamo che foo.eclass e bar.eclass sono definite in src_compile(). Se ereditiamo tutte e due abbiamo una diversa src_compile() dipendentemente dall'ordine in cui ereditiamo foo e bar. Va bene, ora dovreste sapere che dovete mantenere traccia dell'ordine di ereditarietà. Puoi anche però voler chiamare esplicitamente una delle due src_compile().

Quindi, ogni eclass aggiunge un prefisso a ogni funzione definita. Per esempio la eclass foo.eclass definirà una funzione chiamata foo_src_compile() e bar.eclass definirà bar_src_compile(). Così, l'ebuild può chiamare tutte e due le funzioni e saprà cosa sta facendo.

Comunque, potremmo anche voler avere una funzione di default chiamata solo src_compile(), o l'ebuild dovrà definirne una. La macro EXPORT_FUNCTIONS risolve questo problema e quello iniziale.

EXPORT_FUNCTIONS() {
	while [ "$1" ]; do
		eval "$1() { ${ECLASS}_$1 ; }" > /dev/null
		shift
	done
}

La funzione inherit() setta $ECLASS con il nome della eclass prima di ogni operazione. La eclass, alla sua fine chiama EXPORT_FUNCTIONS(), passando come parametri la lista delle funzioni di default che fornisce. Ad esempio, se chiamate

EXPORT_FUNCTIONS src_compile src_install

EXPORT_FUNCTIONS chiamerà eval() nella seguente stringa:

src_unpack() { foo_src_compile() ; }
src_compile() { foo_src_compile() ; }

Ora, qualsiasi eclass ereditata per ultima, definirà la funzione default di src_compile() ma ogni funzione potrà essere chiamata direttamente dall'ebuild se necessario.

Potete anche estendere la default src_compile() chiamando la funzione eclass dalla vostra funzione. Dovete allora usare il nome intero della funzione di default foo_src_compile(), un esempio:

#in foo.eclass:
foo_src_compile() {
	[default code here]
}

EXPORT_FUNCTIONS src_compile
#end eclass code

#in an ebuild:
inherit foo

src_compile() {
	[codice personalizzato]
	foo_src_compile
	[ancora codice personalizzato]
}

Sezioni delle funzioni 

Talvolta, estendere le funzioni di default aggiungendo codice prima e dopo non è abbastanza flessibile. Quando si ha a che fare con funzioni lunghe e complesse, spesso vorrete avere il vostro codice personalizzato in mezzo a queste funzioni.

Le sezioni delle funzioni permettono una grande flessibilità in questo. Esse dividono le funzioni in varie sezioni e vi permettono di eseguire codice fra le sezioni.

L'implementazione è semplice. Prendiamo un esempio di src_compile() da base.eclass. (Nota: non esiste ma è un buon esempio :-) Appare come segue:

base_src_compile() {
    ./configure || die
    emake || die
}

Qua abbiamo la stessa funzione, divisa in due sezioni:

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
}

Il codice è stato diviso in due sezioni: configure e make. Nel nostro semplice esempio, esse corrispondono ai due comandi della funzione originale.

Al centro della nuova funzione troviamo un blocco while;case...esac;shift;done. Questo blocco trova i parametri della funzione con i nomi della sezione definita ed esegue le linee di codice corrispondenti.

Il caso speciale all chiama la stessa funzione ricorsivamente con una lista di sezioni ordinate. E` compito dell'autore della eclass aggiornare questa lista.

La linea prima del blocco di codice dice che una chiamata senza parametri deve essere trattata come una chiamata con singolo parametro all. Come potete vedere, questa funzione si richiama molto. Notate, comunque, che la chiamata base_src_compile configure all make è comunque lecita; essa eseguirà base_src_compile configure configure make make.

Ora, nel vostro ebuild (o eclass) che eredita le funzioni da base.eclass, avete la funzione abbreviata src_compile che chiama base_src_compile senza parametri. Ciò esegue base_src_compile all, ossia, tutte le sue sezioni. Potete lasciare tutto com'è. Se volete estendere, potete definire una nuova src_compile e chiamare base_src_compile una sezione per volta:

src_compile() {
    run_my_code1
    base_src_compile configure
    run_my_code2
    base_src_compile make
    run_my_code3
}

Come potete vedere, le sezioni aggiungono flessibilità quando potete inserire codice fra due di esse, lo fanno anche quando esse vengono eseguite in un ordine differente da quello prestabilito o si esegue sono qualcuna delle sezioni disponibili. Ciò permette un grande riutilizzo di codice.

Le funzioni debug-print-* 

Queste sono altre funzioni fornite da ebuild.sh. Esse aggiungono un output dettagliato per il debug alle eclasses, per permettervi di tracciare la loro esecuzione più facilmente senza dover leggere le lunghe tracce lasciate dal semplice debugging di bash. Tutte le mie eclasses chiamano molto queste funzioni.

debug-print() stampa semplicemente tutti i suoi parametri con il prefisso 'debug:'. Viene chiamata quando c'è qualcosa di interessante da mettere nel log di debug.

debug-print-function() stampa 'debug: entro nella funzione $1, parametri: $2 [$3 ...-] Viene chiamata all'inizio di una funzione.

debug-print-section() stampa 'debug: entro nella sezione $1'. Viene chiamata all'inizio di una sezione di funzione.

L'ouput di debug va normalmente in $T/eclass-debug.log. Potete settare la variabile d'ambiente ECLASS_DEBUG_OUTPUT (in make.globals/conf o nell'ambiente stesso) e l'output verrà mandato tranquillamente dove specificato. Potete anche settarla nel valore speciale 'on', che visualizza l'output nell'stdout con i messaggi di emerge.

Aggiungiamo un'output di debug tipico alla nostra funzione di esempio:

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"
}

FYI, $FUNCNAME è un builtin bash che restituisce il nome della funzione corrente.

2.Eclasses esistenti

Introduzione 

Molte eclasses sono semplici, e potete semplicemente leggerle e dare un'occhiata agli ebuild che le usano per capire come funzionano. Molte eclasses sono ben-commentate, quindi è meglio leggerle.

Questo capitolo del documenta le relazioni fra le eclasses kde*.

base.eclass 

Questa eclass definisce alcune variabili di default e funzioni, simili a quelle che potete avere di default in un ebuild non ereditario (definite in ebuild.sh). Probabilmente non sarete interessati a utilizzarla direttamente ma tramite una delle eclasses kde che la eredita.

Un'interessante funzionalità che fornisce è la capacità autopatch. Se settate la variabile PATCHES per contenere una lista di files nel vostro ebuild che usa base_src_unpack() (o kde_src_unpack()), i sorgenti verranno patchati da questi files. Le patch necessitano il parametro -p0 quando vengono eseguite da $S.

Nota che potete settare PATCHES senza definire una src_unpack() personalizzata nel vostro ebuild! E` fatta apposta.

La nuova funzione epatch() proveniente da eutils.eclass è molto più potente - supporta patch compresse, directory di patch e serie, più la detection automatica del livello di patch - e intendo utilizzarla per autopatch.

Notate che la sezione patch in base_src_unpack() è deprecata e verrà rimossa. Se vedete un ebuild che la utilizza, ha bisogno di essere convertita nello stile autopatch.

kde-functions.eclass 

Questa eclass contiene tutte le funzioni d'aiuto in relazione con KDE. Alcun di esse non dovranno mai essere usate in un ebuild; esse non sono menzionate qu e dovranno essere ben commentate nei sorgenti.

Notate che per "funzioni di aiuto" intendo funzioni che non sono specifiche degli ebuild (src_unpack() etc.). Tutte le eclasses KDE contentgono funzioni speciali che ereditano funzioni kde.

Il solo codice fuori dalle funzioni in kde-functions.eclass è un blocco che determina se l'ebuild corrente fa parte di kde-base. Se si, KDEBASE=true viene settata. Questa variabile viene usata in vari test logici ed è comodo avere un test centralizzato per essa.

Lo schema corrente multi-kdedir

Una breve spiegazione su come Gentoo gestisce le versioni multiple di KDE:

KDE (da kde-base) è situata in /usr/kde/${major version}.{minor version}. Quindi, KDE 3.1.x sta in /usr/kde/3.1. Comunque, questo schema è stato stabilito dopo la release 3.0 di KDE e le versioni vecchie stanno nelle locazioni non standard: KDE 3.0.x sta in /usr/kde/3 (non in /usr/kde/3.0) e KDE 2.2.2 (la sola versione 2.x che abbiamo) sta in /usr/kde/2. Gli ebuild cvs che mantengo installano in /usr/kde/cvs.

Un numero diverso di minor versions di KDE possono coesistere. I pacchetti kde-base hanno una SLOT major.minor (es. 3.0, 3.1).

Da quando le versioni QT sono considerate completamente compatibili indipendentemente dalle minor versions, abbiamo solo ognuna delle major version installate con slot diversi; esse risiedono in /usr/qt/$major.

Un ebuild non-kde-base installa sempre in /usr. Il pacchetto kde-env mette KDEDIRS=/usr in env.d, permettendo a queste applicazioni di essere eseguite in maniera corretta. La applicazione si compila e si linka con le ultime librerie KDE sul sistema; la eclass controlla le locazioni standard in ordine discendente - /usr/kde/cvs, poi /usr/kde/3.1 poi /usr/kde/3 (gli ebuild kde-base si linkeranno sempre con le kdelibs della loro versione) Questo dipende anche dai parametri passati a need-kde() (guarda più giù).

Esistono diverse variabili speciali che potete configurare per cambiare i settaggi di default di questo sistema. Il loro uso primario è compilare un ebuild con un KDE specifico installato da voi per testing, ma, potete anche usarlo per installare KDE in una locazione non standard e avere KDE 3.0.1 e 3.0.2 installati. Questo, ancora, è più utile per testing e sviluppo.

Tutte le applicazioni KDE (base e non base) verranno installate in $KDEPREFIX se esiste. Questo sovrascrive tutti gli altri settaggi delle eclasses.

Una applicazione KDE (sempre che sia kde-base) proverà a linkarsi sulle kdelibs installate in $KDELIBSDIR, se esiste. Se fallisce, tornerà sulla locazione di default di prima delle ultime kdelibs (o la versione propria per la versione kde-base).

need-kde(), need-qt(), set-kdedir(), set-qtdir()

kde-functions.eclass fornisce due paia di funzioni: need-kde(), need-qt() and set-kdedir(), set-qtdir(). Queste funzioni gestiscono i dettagli di molti settaggi KDE e QT.

La funzione need-kde() viene chiamata con un parametro che è la versione minima delle kdelibs di cui si necessita. Essa aggiunge le dipendenze a DEPEND, RDEPEND e chiama la funzione set-kdedir(). Se non viene passato nessun parametro un numero di versione 0 viene usato, ciAoA significa che ogni versione può soddisfare la dipendenza. need-kde() chiama anche need-autoconf() e need-automake() con i parametri necessari per la versione di KDE.

La funzione set-kdedir() allora determina il prefisso dell'installazione e la directory delle kdelibs che il vostro ebuild userà. Essi vengono passati a voi rispettivamente in $PREFIX e $KDEDIR (e sono gestiti automaticamente in kde.eclass). Notate che nessun ebuild deve indirizzare direttamente $KDEPREFIX o $KDELIBSDIR.

need-kde() controlla anche la versione minima di QT richiesta per questa versione delle kdelibs da una tabella. Quindi chiama need-qt() con questa versione. Un'applicazione qt-only (es. non kde) chiama sempre direttamente need-qt, bypassando need-kde.

La funzione need-qt() aggiunge la versione di QT necessaria a DEPEND, RDEPEND e chiama set-qtdir() con essa. La funzione set-qtdir() configura QTDIR con la locazione di default della versione di QT corrente. A differenza di set-kdedir(), set-qtdir() non controlla se c'è QT installato nella locazione.

need-kde() (o need-qt()) deve essere chiamata dalla parte principale dell'ebuild (non da una funzione), così che ogni cambiamento a DEPEND e RDEPEND agiscano su emerge.

need-autoconf(), need-automake()

Queste funzioni settano le variabili d'ambiente necessarie per far girare le versioni richieste di autoconf e automake. Eliminano anche i settaggi delle vecchoie variabili di questo tipo. Per esempio, chiamando 'need-automake 1.4' configurerà NEED_AUTOMAKE_1_4=1 e toglierà tutte le altre variabili WANT_AUTOMAKE*. Per maggiori informazioni controllate il codice delle funzioni e i commenti all'inizio di /usr/bin/auto{conf.make} (in un sistema Gentoo).

kde_sandbox_patch()

Alcuni makefile KDE non funzionano. Essi chmoddano o chownano i files in PREFIX quando li installano ma non rispettano DESTDIR ($D). Ad esempio quando si installa, essi copiano correttamente un file in $DESTDIR/$PREFIX/percorso/foo, ma quando provano a fare chmod +x il path $PREFIX/percorso/foo non sempre esiste. E se esiste, la sandbox previene questa operazione.

Questa funzione esegue un sed generico nei makefiles che sistemano tutti i casi di questo problema. Viene chiamata con le directory da processare come parametri e processa Makefile, Makefile.in e Makefile.am in queste directory. Per esempio:

src_unpack() {
    base_src_unpack
    kde_sandbox_patch ${S}/dir1 ${S}/dir2/dir3
}

kde_remove_flag()

Questa funzione viene utilizzata per togliere le flag al compilatore che si sa possano rovinare il pacchetto. Potete chiamarla dopo l'unpacking, con la subdirectory $S come primo parametro e il nome della flag da rimuovere come secondo. Notate che non è ricorsiva. Esempio "kde_remove_flag foodir/barfoo -fomit-frame-pointer".

kde_remove_dir() and $KDE_REMOVE_DIR

Questa funzione toglie la subdirectory specificata dalla compilazione. Essa la rimuove e rimuove ogni sua occorrenza dal file subdirs, da configure e dai makefiles. Notate che funziona solo nelle subdir di $S per ora, non in subdir di secondo livello. Potete chiamarla con una lista di subdirectory da cancellare; funziona a turno con tutti i parametri.

Potete chiamarla direttamente ma per evitare di definire una src_unpack() personalizzata, fate questo, potete settare in KDE_REMOVE_DIR una lista di directory da rimuovere. kde_src_unpack() chiamerà 'kde_remove_dir $KDE_REMOVE_DIR' dopo l'unpacking. Come potete vedere, Sono andato molto avanti per evitare di dover definire una funzione extra in un ebuild, visto che ciò permette di costruire un ebuild più pulito e leggibile.

kde.eclass 

Questa è la eclass principale di KDE. Essa contiene molto del codice in relazione a KDE. Tutti gli ebuild KDE la ereditano, in un modo o nell'altro. La eclass kde eredita base e kde-functions.

Come per le altre eclasses, leggetela per trovare cosa fa. Molte cose si spiegano da sè. Qua abbiamo un breve sommario:

La sezione globale della eclass (quella che viene eseguita quando si eredita) aggiunge nelle dipendenze correnti kde-env, automake, autoconf, make e perl (l'ultimo utilizzato dagli script standard configure per la generazione veloce di makefile), essa setta anche lo slot di default a 0.

kde_src_unpack() chiama base_src_unpack(), passando parametri (es. sezioni da eseguire). Dopo questo, aggiunge elementi specifici di kde. Esegue touch su tutti i files .ui nei sorgenti scompattati per rigenerare tutti i file stantii .cpp e .h. Chiama anche kde_remove_dir() con $KDE_REMOVE_DIR se è settata (guarda nella sezione kde-functions).

kde_src_compile() ha varie correzioni. Una è l'esportazione di kde_widgetdir="$KDEDIR/lib/kde3/plugins/designer" per girare attorno a un bug nei vecchi acinclude.m4.in di kde. Un altro è settare HOME="$T/fakehome", così che ogni accesso a $HOME/.kde e $HOME/.qt non venga stoppato dalla sandbox e non abbia effetto sulla home dell'utente. E` un bug di uic che prova sempre ad accedere ai config files in quelle locazioni.

kde_src_compile() ha varie sezioni. myconf aggiunge a $myconf i parametri di default degli script configure di kde, come --prefix=${PREFIX} (ricordate, $PREFIX viene settato da set-kdedir()). Potete aggiungere i vostri valori personalizzati in $myconf prima o dopo questa sezione; ricordate solo di non sovrascrivere i vecchi valori perchè gli utenti potrebbero voler settare $myconf nella shell e aggiungere così qualcosa ai parametri configure usati dall'ebuild.

La sezione configure esegue lo script configure in $S, passandogli $myconf. Se lo script configure non esiste, prova a generarlo eseguendo make -f Makefile.cvs o make -f admin/Makefile.common. Così, questo passaggio della compilazione (che è necessario per le snapshots cvs o per gli ebuild che patchano files come configure.in) viene eseguito automaticamente.

La sezione make esegue semplicemente emake || die. Infine, esiste una sezione all che esegue tutto quello che è stato sopra descritto.

Infine, kde_src_install() ha una sezione make che esegue make install e ha anche una sezione dodoc che esegue dodoc in alcuni nomi di documenti standard in $S, come ad esempio README e COPYING.

kde-base.eclass 

Questa eclass ora e' deprecata, le applicazioni devono essere ereditate da kde.

kde.org.eclass 

Anche questa eclass e' deprecata e tutto il codice e' stato spostato a kde-dist.eclass.

kde-dist.eclass 

Questa eclass è per i pacchetti della distribuzione di base di kde in kde-base/*, eredita kde.

Setta in maniera corretta DESCRIPTION e HOMEPAGE e chiama need-kde $PV. Il più semplice e piccolo pacchetto di base per kde (es. kdetoys) non ha bisogno di modificarla in alcun modo; la maggior parte degli ebuild aggiungono solo dipendenze e patches.

kde-i18n.eclass 

Questa eclass serve ai pacchetti kde-i18n-*. Infatti, tutti gli ebuild kde-i18n sono completamente identici e quello che devono fare è ereditare questa eclass. Le loro variabili $P, $P e $PV fanno il resto.

koffice-i18n.eclass 

Questa eclass serve ai pacchetti koffice-i18n-* ed è molto simile a kde-i18n.eclass. Ancora, tutti gli ebuild koffice-i18n sono identici e tutto quello che devono fare è ereditare questa eclass.

cvs.eclass 

Questa eclass provvede a fornire le funzionalità necessarie a creare gli ebuild 'live' cvs. Questi ebuild scaricano i sorgenti dal server cvs specificato a tempo di unpack, prendendo gli ultimi bug e le fix dall'upstream.

Comunque, il supporto necessario per i live cvs ebuilds non è stato aggiungo a portage. Gli ebuild possono lavorare con questa eclass ma non è molto conveniente per alcuni aspetti. Pensateci due volte prima di creare un live cvs ebuild; forse un cvs snapshot regolare sarebbe meglio. Se intendete aggiungere un ebuild di questo tipo al portage, fate attenzione alle guide ai cvs ebuild nella guida dello sviluppatore.

Prima di ereditare cvs.eclass, settate tutti i settaggi non-default che volete (almeno l'indirizzo del server e il nome del modulo). Guardate la lista dei settaggi configurabili e di quelli di default all'inizio di cvs.eclass, marcato come 'ebuld-configurable settings'.

Dopo questo, le cose sono automatiche. Una cvs_src_unpack() (senza sezioni) viene eseguita. Se volete sapere di più leggete la eclass.

kde-source.eclass 

Questa eclass lavora su cvs.eclass, aggiugendo alcune funzionalità specifiche per kde. Per esempio essa scarica automaticamente la directory admin dal modulo common del cvs kde. Leggete la eclass per sapere di più, includendo i settaggi kde-cvs-specific che potete passargli.

3.Writing KDE ebuilds

Introduzione 

Questo capitolo spiega come scrivere ebuild standard per KDE. Tutto quello che viene detto qui è un riassunto delle informazionu sulle eclasses sopra. Quando siete in dubbio, guardate gli altri ebuild, le eclasses o chiedete.

Un tipico ebuild KDE 

Il codice qua sotto dovrebbe essere ovvio dopo aver letto questo howto:

<header lines>
inherit kde

Alcuni ebuild finiscono qua. Altri hanno bisogno di qualche personalizzazione.

Il prossimo passo è aggiungere ogni dipendenza extra. Ricordate: estendete *sempre* le variabili, non sovrascrivetele!

Visto che il nostro obbiettivo è evitare funzioni personalizzate finchè non ne abbiamo bisogno, cerchiamo di configurare tutti i settaggi che possiamo e chiamare le funzioni di aiuto più che possiamo, direttamente dalla main section dell'ebuild. Ricordate che ci sono delle limitazioni nel codice della main section; per esempio, esso non deve produrre alcun output (debug-print() non conta).

DEPEND="foo/bar"
RDEPEND="bar/foo"

In Alternativa, una chiamata a newdepend() aggiungerà la dipendenza in DEPEND e RDEPEND:

newdepend "foo? ( bar )"

Possiamo anche voler aggiungere alcuni argomenti extra a myconf, che verranno passati a configure (assumendo che noi usiamo la sezione configure di kde_src_compile):

myconf="$myconf --with-foobar"

Possiamo anche voler aggiungere una patch. Se essa può essere applicata utilizzando -p0 in $S, possiamo usare la sezione autopatch di base_src_unpack. Ricordate, kde_src_unpack() chiama base_src_unpack() passandogli tutti i parametri che gli date.

PATCHES="$FILESDIR/$P-myfix.diff"

Infine, possiamo voler usare extend_src_install() per mettere a posto la documentazione:

src_unpack() {
    kde_src_install
    dodoc $S/doc/*
}

Guardiamo l'ebuild che abbiamo creato in questo esempio:

<header lines>
inherit kde

# add deps
DEPEND="foo/bar"
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/*
}

Un tipico ebuild con funzionalità opzionali di KDE 

Quando aggiungete la funzionalità (eclass) kde a un ebuild esistente, dovete sempre prefissare ogni linea specifica kde con use kde &&, o creare blocchu if [ -n "`use kde`" ]; then; fi.

Nella sezione generale, aggiugete ciò che segue (solo se USE kde è settato):

    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"

Dopo, dite alla vostra applicazione di vedere se c'è KDE nel settaggio $KDEDIR disponibile dopo la chiamata a need-kde(). Se non volete che venga aggiunta la dipendenza kdelibs, chiamate set-kdedir invece di need-kde().