La structure de construction
Générer du code source pour un habillage d'API dans le style gtkmm requiert l'utilisation d'outils tels que gmmproc et generate_wrap_init.pl. En théorie, vous pouvez écrire vos propres fichiers de construction pour utiliser ces outils de manière appropriée, mais l'utilisation de l'infrastructure de construction fournie par le module mm-common est un meilleur choix. Prendre un module de liaison existant à titre d'exemple et l'examiner est un bon début.
Par exemple, disons que nous habillons une bibliothèque C nommée libexample. Elle fournit une API fondée sur GObject dont les types sont nommés, par exemple, ExampleThing et ExampleStuff.
G.I.I. Copie du squelette du projet
Selon la coutume, la librairie habillée s'appellera libsomethingmm. Nous commençons par copier l'arborescence des sources squelettes à partir du module mm-common.
$ git clone git://git.gnome.org/mm-common $ cp -a mm-common/skeletonmm libsomethingmm
Cet arbre fournit une structure de répertoires pour les fichiers sources .hg et .ccg et pour les fichiers générés .h and .cc ; à l'aide du fichier filelist.am, Automake inclut des fichiers qui peuvent indiquer les divers fichiers utilisés sous forme de variables génériques Automake. L'arborescence ressemble alors à quelque chose comme cela après avoir renommé les répertoires de façon appropriée :
-
libsomethingmm : le répertoire de plus haut niveau.
-
libsomething : contient le fichier include principal et le fichier pkg-config .pc.
src : contient les fichiers source .hg et .ccg.
-
libsomethingmm : contient les fichiers .h et .cc générés et écrits à la main.
- private : contient les fichiers générés *_p.h.
-
De la même manière que nous avons renommé les répertoires, nous devons renommer certains fichiers sources. Par exemple :
$ for f in $(find libsomethingmm -depth -name '*skeleton*'); do \
d="${f%/*}"; b="${f##*/}"; mv "$f" "$d/${b//skeleton/libsomething}"; \
done
Notez que les fichiers avec l'extension .in seront utilisés pour générer des fichiers de même nom, mais sans extension, en remplaçant certaines variables par leur vraie valeur pendant la phase de traitement par le script configure.
G.I.II. Modification des fichiers de construction
Maintenant nous modifions les fichiers pour les adapter à nos besoins. Il se peut que préfériez utiliser un utilitaire rechercher-remplacer agissant sur plusieurs fichiers pour cette opération, comme regexxer. Notez que pratiquement tous les fichiers fournis avec l'arborescence des sources squelettes contiennent du texte à substituer. Ainsi, les substitutions doivent être effectuées globalement et non pas être limitées aux fichiers Automake et Autoconf.
Toutes les mentions de skeleton doivent être remplacées par le nom adéquat de la bibliothèque C que vous habillez, comme « something » ou « libsomething ». De la même manière, toutes les occurrences de SKELETON doivent être remplacées par « SOMETHING » ou « LIBSOMETHING » et celles de Skeleton par « Something ».
De même, remplacez toutes les occurrences de Joe Hacker par le nom du détenteur du copyright — vous, probablement. Faites de même pour l'adresse courriel [email protected].
- G.I.II.I. configure.ac
- G.I.II.II. Fichiers Makefile.am
- G.I.II.III. Création des fichiers .hg et .ccg
G.I.II.I. configure.ac
Dans configure.ac,
- la ligne AC_CONFIG_SRCDIR() doit mentionner un fichier de votre arborescence source. Vous pouvez modifier cela plus tard si vous ne connaissez pas encore les noms de certains fichiers à créer.
- il est courant pour les modules de liaison de garder trace du numéro de version de la bibliothèque qu'ils habillent. Ainsi, par exemple, si la bibliothèque C est à la version 1.23.4, alors la version initiale du module de liaison sera 1.23.0. Évitez toutefois de démarrer avec un numéro de version mineur pair, car il indique traditionnellement une version stable.
- la ligne AC_CONFIG_HEADERS() est utilisée pour générer deux ou plusieurs fichier d'en-tête de configuration. Le premier fichier d'en-tête de la liste comporte toutes les macros de configuration définies pendant le lancement de configure. Les en-têtes restants de la liste ne contiennent qu'un sous-ensemble des macros de configuration et leur fichier configh.h.in correspondant ne sera pas généré automatiquement. La raison de cette séparation est que les en-têtes de configuration avec une espace dans le nom sont installées dans votre bibliothèque et définissent des macros visibles publiquement.
- il se peut que la ligne AC_SUBST([SOMETHINGMM_MODULES], ['...']) ait besoin d'être modifiée pour vérifier les dépendances adéquates.
- le bloc AC_CONFIG_FILES() doit mentionner les noms de répertoires corrects, tels que décrits ci-dessus.
G.I.II.II. Fichiers Makefile.am
Ensuite nous devons adapter les divers fichiers Makefile.am :
-
dans skeleton/src/Makefile.am, nous devons mentionner des valeurs correctes pour les variables génériques utilisées autre part dans le système de construction :
- binding_name
le nom de la bibliothèque, comme libsomethingmm.
- wrap_init_flags
des marqueurs additionnels en ligne de commande passés au script generate_wrap_init.pl, tels que le nom de l'espace de noms C++ et le préfixe du répertoire parent des fichiers include.
-
dans skeleton/skeletonmm/Makefile.am, nous devons mentionner des valeurs correctes pour les variables génériques utilisées autre part dans le système de construction :
- lib_LTLIBRARIES
cette variable doit indiquer le nom correct de la bibliothèque, tel qu'utilisé par les noms de variables _SOURCES, _LDFLAGS et _LIBADD. Il est autorisé d'utiliser des variables substituées par configure comme @SOMETHINGMM_API_VERSION@ en tant que partie de noms de variables.
- AM_CPPFLAGS
les options en ligne de commande passées au préprocesseur C.
- AM_CXXFLAGS
les options en ligne de commande passées au compilateur C++.
G.I.II.III. Création des fichiers .hg et .ccg
Vous devez maintenant créer vos premiers fichiers .hg et .ccg pour habiller quelques objets dans la librairie C. Il y a une paire de fichiers sources à titre d'exemple : skeleton.ccg et skeleton.hg. Faites des copies de ces fichiers si nécessaire.
Il faut mentionner tous les fichiers .hg et .ccg dans le fichier skeleton/src/filelist.am, traditionnellement dans la variable files_hg.
Tout fichier source .h et .cc non généré automatiquement doit être placé dans skeleton/skeletonmm/ et énuméré dans skeleton/skeletonmm/filelist.am, traditionnellement dans les variables files_extra_h et files_extra_cc.
Dans le paragraphe Fichiers .hg et .ccg vous pouvez voir la syntaxe utilisée dans ces fichiers.