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.

For instance, let's pretend that we are wrapping a C library called libsomething. It provides a GObject-based API with types named, for instance, SomeWidget and SomeStuff.

G.I.I. Copie du squelette du projet

Typically our wrapper library would be called libsomethingmm. We can start by copying the skeleton source tree from the mm-common module. 

  $ git clone git://git.gnome.org/mm-common
  $ cp -a mm-common/skeletonmm libsomethingmm

This provides a directory structure for the source .hg and .ccg files and the generated .h and .cc files, with filelist.am Automake include files that can specify the various files in use, in terms of generic Automake variables. The directory structure usually looks like this, after we have renamed the directories appropriately:

  • libsomethingmm: The top-level directory.

    • libsomething: Contains the main include file and the pkg-config .pc file.

      • src: Contains .hg and .ccg source files.

      • libsomethingmm: Contains generated and hand-written .h and .cc files.

        • private: Contains generated *_p.h files.

As well as renaming the directories, we should rename some of the source files. For instance: 

$ for f in $(find libsomethingmm -depth -name '*skeleton*'); do \
    d="${f%/*}"; b="${f##*/}"; mv "$f" "$d/${b//skeleton/libsomething}"; \
  done
A number of the skeleton files must still be filled in with project-specific content later.

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

Now we edit the files to adapt them to our needs. You might prefer to use a multiple-file search-replace utility for this, such as regexxer. Note that nearly all of the files provided with the skeleton source tree contain placeholder text. Thus, the substitutions should be performed globally, and not be limited to the Automake and Autoconf files.

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

In configure.ac,

  • The AC_CONFIG_SRCDIR() line must mention a file in our source tree. We can edit this later if we don't yet know the names of any of the files that we will create.
  • It is common for binding modules to track the version number of the library they are wrapping. So, for instance, if the C library is at version 1.23.4, then the initial version of the binding module would be 1.23.0. However, avoid starting with an even minor version number as that usually indicates a stable release.
  • The AC_CONFIG_HEADERS() line is used to generate two or more configuration header files. The first header file in the list contains all configuration macros which are set during the configure run. The remaining headers in the list contain only a subset of configuration macros and their corresponding config.h.in file will not be autogenerated. The reason for this separation is that the namespaced configuration headers are installed with your library and define publically visible macros.
  • The AC_SUBST([SOMETHINGMM_MODULES], ['...']) line may need to be modified to check for the correct dependencies.
  • The AC_CONFIG_FILES() block must mention the correct directory names, as described above.

G.I.II.II. Fichiers Makefile.am

Next we must adapt the various Makefile.am files:

  • In skeleton/src/Makefile.am we must mention the correct values for the generic variables that are used elsewhere in the build system:

    binding_name

    The name of the library, such as libsomethingmm.

    wrap_init_flags

    Additional command-line flags passed to the generate_wrap_init.pl script, such as the C++ namespace and the parent directory prefix of include files.

  • In skeleton/skeletonmm/Makefile.am we must mention the correct values for the generic variables that are used elsewhere in the build system:

    lib_LTLIBRARIES

    This variable must mention the correct library name, and this library name must be used to form the _SOURCES, _LDFLAGS, and _LIBADD variable names. It is permissible to use variables substituted by configure like @SOMETHINGMM_API_VERSION@ as part of the variable names.

    AM_CPPFLAGS

    The command line options passed to the C preprocessor.

    AM_CXXFLAGS

    The command line options passed to the C++ compiler.

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.

La structure de construction Génération des fichiers .defs

À propos