Les fichiers eclass sont des modules de code partagé. Ils sont écrits en bash, et ont la même syntaxe que les ebuilds ordinaires. Ils sont hérités par des ebuilds ou d'autres eclass, pour proposer des configurations par défaut et des fonctionnalités qu'on peut retrouver dans de nombreux ebuilds similaires.
Cela permet d'assurer une condensation du code, en permettant une réutilisation maximum de code entre des ebuilds similaires.
Le premier chapitre montre rapidement comment écrire un eclass, en y incorporant des astuces et techniques standards, utilisés dans des eclass déjà existants. Le second chapitre offre un tour d'horizon des eclasses de KDE. Le troisième explique comment créer un ebuild pour KDE en utilisant le groupe d'eclass de KDE.
Voici un fichier eclass fictif : sourceforge.eclass, créé pour proposer la page Internet principale et des URIs de téléchargement pour des projets hébergés par sourceforge.net.
# Copyright 2004 Gentoo Foundation
# 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/proj/en/devrel/handbook/hb-guide-eclass.xml,v 1.1 2004/07/17 21:05:00 plasmaroo Exp $
ECLASS=sourceforge
INHERITED="$INHERITED $ECLASS"
# This eclass sets $HOMEPAGE and $SRC_URI to the standard values for
# sourceforge.net - hosted projects.
HOMEPAGE="http://${PN}.sourceforge.net/"
SRC_URI="http://download.sourceforge.net/${PN}/${P}.tar.gz"
Les quatre premières lignes forment l'en-tête, tout comme ce qu'on peut trouver dans n'importe quel ebuild. Les deux lignes suivantes sont une description rapide de l'eclass. Le reste du code est ce qui fait effectivement le travail : initialiser SRC_URI et HOMEPAGE.
La plupart des eclass proposent des fonctions d'aide ou des déclarations de variables : ils contiennent les versions par défaut des fonctions spéciales d'ebuild (src_unpack, src_compile, etc.). Avant d'écrire une fonction par défaut dans un eclass, vous devriez prendre connaissance des fonctions par défaut déjà contenues dans ebuild.sh. Elles contiennent les fonctions qui seront exécutées si vous n'incluez pas de fonctions dans votre ebuild (même pas en passant par un eclass) : src_unpack() par exemple, est une fonction par défaut qui est souvent utilisée. Si vous ne l'avez pas encore fait, jetez un oeil dans les implémentations par défaut dans ebuild.sh.
C'est tout ce que vous avez besoin de savoir pour écrire des fichiers eclass.
Mettez votre nouvel eclass dans
inherit sourceforge
Les contenus de l'eclass seront insérés à cet endroit. Souvenez-vous que toutes les fonctions et variables définies dans l'eclass peuvent être réécrites dans l'ebuild, dans la mesure où le code de l'ebuild sera exécuté après celui de tous les eclass dont il hérite. De ce fait, vous devez essayer de mettre le plus possible de configuration par défaut et de code mis en commun dans votre eclass. Toutes les modifications et configurations non-standards peuvent être mis dans l'ebuild.
Et vous pouvez bien sûr faire hériter un ebuild de plusieurs eclass, en procédant ainsi :
inherit eclass1 eclass2 [...]
... mais faites attention à l'ordre dans lequel ils sont mis ! Souvenez-vous, les eclass peuvent hériter d'autres eclass, et remplacer les configurations créées par d'autres, donc vous devez faire attention quand vous utilisez plusieurs eclass à la fois.
Nous allons maintenant donner une liste de petits trucs utiles pour l'écriture d'eclass, avant d'aller voir les eclass déjà présents dans Portage.
Cette fonction est présente dans ebuild.sh et permet l'héritage des eclass. Elle est appelée avec la liste des noms d'eclass à faire hériter : inherit <eclass1> [eclass2 eclass3...].
En plus de récupérer effectivement les sources des fichiers eclass, elle va mettre à jour les variables ECLASS et INHERITED qui sont utilisées par Portage pour mettre en tampon les dates de dernière modification des eclass. La variable INHERITED peut également être utilisée lors de l'écriture d'un fichier eclass : elle contient la liste des eclass hérités (dont la source a été récupérée) jusqu'au moment de la vérification, dans l'ordre. De ce fait, un eclass peut l'utiliser pour déterminer si oui ou non il a été appelé par d'autres eclass.
Un bon set de fonctions prédéfinies dans un eclass peut souvent être utilisé comme tel. L'ebuild contiendra alors très peu de code (ce qui est une bonne chose). Cependant, les fonctions d'un eclass ne font parfois pas ce que l'on attend d'elles. Vous pouvez écrire une nouvelle fonction dans votre ebuild, en écrasant ainsi la définition proposée par l'eclass. Mais cela diminue l'avantage d'avoir un code réutilisable. Nous essayons donc, à la place, d'« étendre » les fonctions des eclass.
Supposons que vous vouliez étendre src_compile(). Vous pouvez écrire une définition de src_compile(), qui ne contiendra que les parties manquantes de l'eclass src_compile(). Vous pouvez alors appeler l'eclass contenant src_compile() et exploiter le code de votre fonction personnalisée.
Mais si vous créez une nouvelle fonction src_compile(), bash oubliera l'ancienne et ne sera pas capable de l'appeler ! C'est ici que la macro EXPORT_FUNCTIONS entre en jeu.
Observons un autre problème en attendant la solution. Supposons que foo.eclass et bar.eclass définissent tous les deux src_compile(). Si vous héritez à la fois de foo et de bar, vous aurez à votre disposition plusieurs implémentations de src_compile(), selon l'ordre d'héritage que vous avez déclaré. Vous devez donc garder un oeil sur l'ordre de l'héritage des eclass. Mais vous pouvez vouloir appeler de manière explicite n'importe lequel des deux src_compile().
Donc, tous les eclass ajoutent à leurs fonctions qu'ils définissent un préfixe. Du coup, foo.eclass va définir une fonction foo_src_compile(), et bar.eclass définira de son côté bar_src_compile(). De cette manière, l'ebuild peut appeler les deux fonctions sans problème.
Cela dit, vous voulez également avoir une fonction générique src_compile(), ou peut-être même que l'ebuild en a une déjà définie. La macro EXPORT_FUNCTIONS résout les deux problèmes présentés précédemment.
EXPORT_FUNCTIONS() {
while [ "$1" ]; do
eval "$1() { ${ECLASS}_$1 ; }" > /dev/null
shift
done
}
La fonction inherit() initialise $ECLASS au nom de l'eclass avant de récupérer les sources. L'eclass, à la fin, appelle EXPORT_FUNCTIONS() en lui passant comme paramètres la liste des fonctions par défaut qu'il propose. Par exemple, si vous appelez :
EXPORT_FUNCTIONS src_compile src_install
Alors, EXPORT_FUNCTIONS appellera eval() sur les chaînes de caractères suivantes :
src_unpack() { foo_src_compile() ; }
src_compile() { foo_src_compile() ; }
Maintenant, n'importe quel eclass hérité définira la fonction par défaut src_compile() à la fin, mais les deux fonctions peuvent également être appelées par l'ebuild si nécessaire.
Vous pouvez également étendre la fonction src_compile() en appelant la fonction de l'eclass à l'intérieur de votre propre fonction. Vous devez alors utiliser le nom complet de la fonction par défaut foo_src_compile. Par exemple :
#dans foo.eclass:
foo_src_compile() {
[code par défaut ici]
}
EXPORT_FUNCTIONS src_compile
#fin du code de l'eclass
#dans un ebuild:
inherit foo
src_compile() {
[code personnalisé ici]
foo_src_compile
[plus de code personnalisé ici]
}
Parfois, les fonctions étendues par défaut, parce que du code est exécuté avant et après, ne sont pas assez flexibles. Lorsqu'on s'occupe de fonctions longues et complexes, on veut parfois pouvoir utiliser son propre code au milieu d'autres fonctions.
Les sections de fonction proposent une plus grande flexibilité, qui nous permet de s'affranchir du problème soulevé. Elles cassent les fonctions en sections, et vous permettent d'exécuter du code et ce, entre deux sections quelconques.
L'implémentation est simple. Prenons par exemple la fonction src_compile() depuis base.eclass (Note : il n'existe plus, mais c'est un assez bon exemple). Cette fonction ressemble à ceci :
base_src_compile() {
./configure || die
emake || die
}
Ici on trouve une même fonction, divisée en deux sections :
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
}
Ce code a été divisé en deux sections :
Au centre de notre fonction, on a un bloc while;case...esac;shift;done. Ce bloc vérifie les paramètres passés à la fonction et exécute les lignes de code correspondantes aux paramètres passés.
Le cas particulier
La ligne avant le bloc indique que si on effectue un appel à cette fonction sans
lui donner de paramètres, alors il faut agir de la même manière que si on avait
pour paramètre
Désormais, dans votre ebuild (ou eclass) héritant de base.eclass, vous récupérez
une ébauche de fonction src_compile qui appelle base_src_compile sans paramètre.
Cela est en fait équivalent à un appel de base_src_compile avec pour paramètre
src_compile() {
run_my_code1
base_src_compile configure
run_my_code2
base_src_compile make
run_my_code3
}
Comme vous pouvez le remarquer, les sections de la fonction ajoutent une certaine flexibilité dans la mesure où vous pouvez désormais insérer du code entre deux sections, mais vous pouvez aussi les lancer dans un ordre différent, ou lancer seulement certaines sections proposées. Cela permet d'accroître la réutilisabilité du code.
De nombreuses fonctions sont déjà proposées par ebuild.sh. Certaines d'entre elles, les fonctions debug-print-*, donnent accès à des fonctions de retour d'erreur de débogage pour les eclass. Elles vous permettront de faciliter le traçage de l'exécution de ceux-ci, sans avoir à lire les (très) longs retour de déboggage de bash en mode debug. Par exemple, tous les eclass que j'ai créé appellent énormément ces fonctions.
debug-print() affiche simplement l'ensemble de ses paramètres avec un préfixe en « debug: ». Elle est utilisée quand un événement intéressant peut être mis dans les fichiers log de déboggage.
debug-print-function() affiche « debug: entering function $1, parameters: $2 [$3 ..] ». Elle est communément appelée au début d'une fonction.
debug-print-section() affiche « debug: now in section $1 ». Elle est habituellement appelée au début d'une section de fonction.
Les retours de déboggage vont normalement dans
Ajoutons un retour de déboggage typique pour récupérer l'état d'avancement de l'exécution dans notre fonction exemple :
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"
}
Pour votre information, $FUNCNAME est une variable interne de bash qui retourne le nom de la fonction courante.
La plupart des eclass sont simples et vous pouvez simplement les lire et repérer un certain nombre d'ebuilds utilisant ceux-ci pour comprendre comment ils marchent. De plus, la plupart des eclass sont bien commentés, donc c'est mieux de les lire directement.
Ce chapitre documente les relations existant entre les eclass kde*.
Cet eclass définit plusieurs variables et fonctions par défaut et similaires à celles que l'on aurait dans un ebuild n'héritant pas d'un eclass (et qui sont alors définies dans ebuild.sh). Vous ne les utiliserez probablement pas directement, mais exploiterez des eclass kde qui héritent alors de base.eclass, et utilisent ces fonctions.
Une fonctionnalité intéressante est la capacité d'
Remarquez que vous pouvez initialiser PATCHES sans définir un src_unpack() personnalisé dans votre ebuild ! C'est là l'astuce.
La récente fonction epatch() dans eutils.eclass est cependant bien plus puissante. Elle supporte les correctifs archivés, les répertoires de correctifs et les séries de correctifs, et détecte automatiquement le niveau de correctif requis. Il est probable que autopatch l'utilise un jour ou l'autre.
Remarquez que la section
Cet eclass propose un ensemble de fonctionnalités nécessaires pour créer des ebuilds cvs en « live ». Ce type d'ebuilds récupère les sources sur un serveur cvs spécifique au moment du désarchivage, ce qui permet de toujours avoir les derniers correctifs disponibles.
Cependant, le support nécessaire (exploitation des versions etc.) pour des ebuilds « live » dans un cvs n'a pas encore été ajouté à Portage. Ils peuvent fonctionner avec cet eclass, mais ce n'est pas très pratique, et ce pour plusieurs raisons. Pensez-y à deux fois avant de créer un ebuild de ce type : il est fort probable que récupérer un instantané de cvs sera suffisant voire mieux qu'utiliser cvs.eclass. Si vous essayez d'ajouter un tel ebuild à Portage, appliquez à la lettre le guide d'utilisation de cvs dans les guides pour développeurs.
Avant de faire un héritage de cvs.eclass, initialisez toutes les configurations que vous souhaitez (et qui ne sont pas celles par défaut) ou au moins l'adresse du serveur et le nom du module. Voir la liste des possibilités de configuration et les valeurs par défaut au début du fichier cvs.eclass, marqués comme « ebuild-configurable settings ».
Ensuite, tout se passe de manière plus ou moins automatique. Une fonction (sans section) cvs_src_unpack() est proposée. Si vous voulez en savoir plus, lisez directement l'eclass lui-même.
Cet eclass contient toutes les fonctions d'aide relatives à KDE. Parmi elles, il en est certaines que vous n'utiliserez jamais directement dans un ebuild ; elles ne sont pas mentionnées ici, et sont être suffisamment commentées dans le fichier source.
Par « fonctions d'aide », nous entendons toutes les fonctions qui ne sont pas des fonctions spécifiques aux ebuilds (src_unpack() etc.). Tous les eclass kde contenant de telles fonctions spéciales héritent de kde-functions.
La seule portion de code qui n'appartienne pas à une fonction dans kde-functions.eclass (qui est donc lancé lors de la récupération des fonctions à l'héritage) est un bloc qui détermine si oui ou non l'ebuild actuel est un ebuild de kde-base. Si c'est le cas, on aura KDEBASE=true. Cette variable est utilisée dans plusieurs tests ailleurs, et il est commode d'avoir un test centralisé pour faire cela.
L'arborescence utilisée actuellement pour KDE
Une courte explication sur comment Gentoo gère les multiples versions pour KDE peut être utile :
Une application KDE de kde-base est toujours placée dans
De ce fait, tous les KDEs ayant un numéro de version mineur différent entre eux peuvent coexister sur un même système. Les paquets kde-base ont un SLOT majeur.mineur (par exemple, 3.0, 3.1).
Depuis que les versions mineures de KDE sont supposées utiliser une version de
QT compatible entre les versions mineures, nous n'avons qu'une seule version
majeure installée, avec un slot différent : ils sont dans
Un ebuild autre que kde-base est toujours installé dans
Il y a plusieurs variables spéciales que vous pouvez initialiser pour changer la configuration par défaut du système. Leur première utilité est de compiler un ebuild en utilisant un KDE spécifique que vous avez installé pour faire des tests, mais vous pouvez aussi les utiliser pour installer KDE dans un répertoire non standard, et donc avoir par exemple KDE 3.0.1 et 3.0.2 installés en même temps sur un même système. Encore une fois c'est plus utile pour les tests et le développement que pour une utilisation normale.
Toutes les applications KDE (base et non-base) seront installées dans $KDEPREFIX, s'il est initialisé. Il a priorité sur toutes les actions d'installation dans un répertoire pour tous les eclass.
Une application KDE (même si c'est une application de kde-base) essayera de se lier au kdelibs installé dans $KDELIBSDIR, s'il est initialisé. S'il échoue, il utilisera le processus par défaut expliqué plus haut pour identifier la dernière version de kdelibs (ou la bonne version pour kde-base).
need-kde(), need-qt(), set-kdedir(), set-qtdir()
kde-functions.eclass fournit deux paires de fonctions : need-kde(), need-qt() et set-kdedir(), set-qtdir(). Ces fonctions s'occupent de la mise en place de tous les petits détails pour l'installation de multiples KDEs et QTs.
La fonction need-kde() est appelée avec un paramètre qui est le numéro de version minimal requis pour la bibliothèque kdelibs. Il ajoute les bonnes dépendances à DEPEND, RDEPEND, et appelle la fonction set-kdedir(). Si aucun paramètre n'est donné, le numéro de version 0 sera utilisé, ce qui signifie en fait que toutes les versions satisferont les dépendances requises. need-kde() appelle également need-autoconf() et need-automake() avec les paramètres adaptés à la version de KDE.
La fonction set-kdedir() détermine ensuite le préfixe d'installation et le répertoire pour kdelibs, qui seront utilisés dans votre ebuild. Ils sont ensuite disponibles avec respectivement $PREFIX et $KDEDIR, et sont gérés automatiquement dans kde.eclass. Remarquez qu'aucun ebuild ne devrait initialiser $KDEPREFIX et $KDELIBSDIR directement.
need-kde() regarde également la version minimale de QT requise pour cette version de kdelibs, dans une table. Il appelle ensuite need-qt() avec cette version. L'ebuild d'une application qt-uniquement (c'est-à-dire non-kde) appelle en général directement need-qt(), sans passer par need-kde().
La fonction need-qt() ajoute la version requise de QT dans DEPEND, RDEPEND, puis appelle set-qtdir() avec celle-ci. La fonction set-qtdir() initialise $QTDIR pour qu'il soit le répertoire par défaut de cette version de QT. Contrairement à set-kdedir(), set-qtdir() ne vérifie en fait pas si QT est bien installé où indiqué.
need-kde() (ou need-qt()) doit être appelé depuis la partie principale d'un ebuild (c'est-à-dire pas depuis une fonction), afin que tous les changements effectués sur DEPEND et RDEPEND affectent emerge.
need-autoconf(), need-automake()
Ces fonctions initialisent les variables d'environnement nécessaires pour
pouvoir exécuter les versions requises de autoconf et automake. Elles suppriment
également toutes les variables de ce type initialisées auparavant. Par exemple,
appeler « need-automake 1.4 » supprimera toutes les variables
WANT_AUTOMAKE* et initialisera NEED_AUTOMAKE_1_4 à 1. Pour plus d'informations,
lire le code de ces fonctions et les commentaires au début de
kde_sandbox_patch()
Certains Makefile de KDE sont cassés. Ils effectuent des
Cette fonction lance un
src_unpack() {
base_src_unpack
kde_sandbox_patch ${S}/dir1 ${S}/dir2/dir3
}
kde_remove_flag()
Il sert à ignorer les paramètres passés au compilateur qui sont connus pour
casser les paquets générés. Vous devez l'appeler après avoir préparé l'espace de
travail (dé-archivage des sources ...) en lui donnant comme premier paramètre le
sous-répertoire de travail de $S, et comme second paramètre, le nom d'un
paramètre à enlever. Remarquez que la fonction n'est pas récursive. Un exemple
d'appel à cette fonction serait donc :
kde_remove_dir() et $KDE_REMOVE_DIR
Cette fonction supprime de la compilation un répertoire spécifique. Elle l'efface, et supprime toutes les références à ce répertoire dans le fichier des sous-répertoire configure, et Makefile. Remarquez que cela ne fonctionne que sur des sous-répertoires de $S pour le moment, et ne fonctionne pas non plus pour les sous-répertoires de profondeur supérieure à 2. Vous pouvez l'appeler avec une liste des sous-répertoires à enlever ; elle travaille sur tous les répertoires les uns après les autres.
Vous pouvez l'appeler directement, mais pour éviter d'avoir à définir une
fonction personnalisée pour src_unpack() juste pour cela, vous pouvez
initialiser la variable KDE_REMOVE_DIR à la liste des sous-répertoires à
enlever. kde_src_unpack() appellera
C'est l'eclass principal et central de KDE. Il contient la plupart du code relatif à KDE. Tous les ebuilds pour KDE en héritent d'une manière ou d'une autre. l'eclass kde hérite lui-même de base et de kde-functions.
Comme pour les autres eclass, lisez-le pour trouver ce qu'il fait. La plupart de ses fonctions sont simples et coulent de source. Voici un petit résumé :
La section globale de l'eclass (c'est à dire celle qui est exécutée lors de l'opération d'héritage) ajoute les bonnes dépendances pour kde-env, automake, autoconf, make et perl (le dernier est utilisé par les scripts standards de configuration « configure » pour générer rapidement les Makefile). Il initialise également SLOT="0" par défaut.
kde_src_unpack() appelle simplement base_src_unpack(), en lui passant tous les paramètres nécessaires (par exemple, les sections à exécuter). Ensuite, elle ajoute des petits éléments spécifiques à KDE. Elle touche à tous les fichiers .ui dans les sources non désarchivées, pour regénérer tous les fichiers .cpp et .h. Elle appelle également kde_remove_dir() avec $KDE_REMOVE_DIR comme paramètre si cette variable est bien initialisée (voir plus haut dans la partie sur kde-functions).
kde_src_compile() effectue également un certain nombre d'opérations. Parmi celles-ci, elle exporte kde_widgetdir="$KDEDIR/lib/kde3/plugins/designer" pour contourner un problème rencontré avec les anciens fichiers acinclude.m4.in de KDE. Elle initialise également HOME="$T/fakehome", pour que tous les accès à $HOME/.kde et $HOME/.qt ne soient pas avortés par le sandbox et pour ne pas affecter directement les répertoires des utilisateurs. C'est une erreur de sa part de toujours vouloir accéder aux fichiers de configuration de ces répertoires.
kde_src_compile() comporte différentes sections.
La section
La section
Finalement, kde_src_install() a une section
Cet eclass est maintenant désuet, les ebuilds doivent à la place avoir « inherit kde ».
Cet eclass est pour les paquets de distribution kde core, dans kde-base/*. Il hérite de kde.
Il initialise les variables DESCRIPTION et HOMEPAGE correctement et appelle
Cet eclass est fait pour les paquets kde-i18n-*. En fait, tous les ebuilds kde-i18n sont rigoureusement identiques, et donc tout ce qu'ils ont à faire est d'hériter de cet eclass. Leurs variables $P, $PV, feront le reste.
Cet eclass est également désuet, et tout son code a été déplacé dans kde-dist.eclass.
Cet eclass est fait pour les paquets de koffice-i18n-* et est très similaire à kde-i18n.eclass. Encore une fois, tous les ebuilds koffice-i18n sont identiques et tout ce qu'ils ont à faire est d'hériter de cet eclass.
Cet eclass travaille à un niveau au dessus de cvs.eclass, en ajoutant quelques
fonctionnalités spécifiques à KDE. Par exemple, il récupère automatiquement le
répertoire
Ce chapitre explique comment écrire des ebuilds pour KDE. Tout ce qui est dit ici est une récupération et restructuration des informations présentes dans les eclass cités plus haut. Si vous avez un doute quelconque, allez voir d'autres ebuild, lire les eclass, ou demandez tout simplement.
Le code ci-dessous devrait être évident pour vous après avoir lu ce HOWTO :
<Les en-têtes vont ici...> inherit kde
Certains ebuilds finissent directement ici. D'autres ont besoin d'un peu de personnalisation.
L'étape suivante est l'ajout de toutes les dépendances supplémentaires. Souvenez-vous : toujours ajouter aux variables, jamais les écraser !
Parce que notre objectif est d'éviter de définir des fonctions personnalisées dans nos ebuilds, sauf si c'est vraiment nécessaire, nous initialisons tout ce qu'on peut initialiser, et appelons toutes les fonctions d'aide possible, directement dans la section principale de l'ebuild. Souvenez-vous cependant qu'il y a des limitations dans le code de la section principale ; par exemple il ne doit pas produire de sortie (à l'exclusion a priori de l'utilisation raisonnable de debug-print()).
DEPEND="foo/bar" RDEPEND="bar/foo"
Vous pouvez également vouloir ajouter quelques arguments supplémentaires à
myconf, qui seront ensuite passés à ./configure (en supposant qu'on utilise la
section
myconf="$myconf --with-foobar"
Nous avons également un correctif à ajouter. S'il peut s'appliquer en utilisant
le paramètre -p0 dans $S, vous pouvez utiliser la section
PATCHES="$FILESDIR/$P-myfix.diff"
Finalement, nous voulons une version étendue de src_install() pour s'occuper également de certaines documentations :
src_unpack() {
kde_src_install
dodoc $S/doc/*
}
Regardons maintenant l'ebuild que nous avons créé dans notre exemple :
<Les en-têtes vont ici...>
inherit kde
# add deps
DEPEND="foo/bar"
RDEPEND="bar/foo"
# 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/*
}
Quand vous ajoutez une fonctionnalité KDE (eclass) à un ebuild existant vous
n'avez qu'à préfixer toutes les lignes spécifiques à KDE avec
Dans la section générale, ajoutez les lignes suivantes (seulement si le paramètre USE kde est mis, évidemment) :
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"
Ensuite, indiquez à votre application de rechercher KDE dans la configuration $KDEDIR qui est disponible après un appel de need-kde(). Si vous ne voulez pas ajouter les dépendances à kdelibs, appelez set-kdedir() à la place de need-kde().