Table of Contents
gtkmm uses the gmmproc tool to generate most of its source code, using .defs files that define the APIs of GObject-based libraries. So it's quite easy to create additional gtkmm-style wrappers of other glib/GObject-based libraries.
This involves a variety of tools and some copying of existing build files, but it does at least work, and has been used successfully by several projects.
Generation of the source code for a gtkmm-style wrapper API requires use of tools such as gmmproc and generate_wrap_init.pl. In theory you could write your own build files to use these appropriately, but in practice it's usually easier to simply copy an existing project and modify it for your needs. Note however, that there is plenty of scope for improvement in the build structure that we use, so try to copy the latest version, and feel free to suggest improvements to make it more generic.
For instance, let's pretend that we are wrapping a C library called libexample. It provides a GObject-based API with types named, for instance, ExampleThing and ExampleStuff.
Typically our wrapper library would be called libexamplemm. We can start by copying an existing *mm library, such as libgdamm, after checking it out from cvs.
$ cvs -z3 co gnomemm/libgdamm $ cp -r gnomemm/libgdamm libsomethingmm
This provides a directory structure for the source .hg and .ccg files and the generated .h and .cc files, with Makefile.am fragments that can specify the various files in use, in terms of generic Makefile.am variables. The directory structure usually looks like this, after we have renamed the directories appropriately:
As well as renaming the directories, we should rename some of the source files. For instance:
$ mv libsomething/libgdamm-2.0.pc.in libsomething/libsomethingmm-1.0.pc.in $ mv libsomething/libgdammconfig.h.in libsomething/libsomethingmmconfig.h.in $ mv libsomething/libgdamm.h libsomething/libsomethingmm.h $ $ mv libsomething/src/libgda.defs libsomething/src/libsomething.defs $ mv libsomething/src/libgda_enums.defs libsomething/src/libsomething_enums.defs $ mv libsomething/src/libgda_methods.defs libsomething/src/libsomething_methods.defs $ mv libsomething/src/libgda_others.defs libsomething/src/libsomething_others.defs $ mv libsomething/src/libgda_signals.defs libsomething/src/libsomething_signals.defs $ mv libsomething/src/libgda_vfuncs.defs libsomething/src/libsomething_vfuncs.defs $ mv libsomething/src/libgda_docs.xml libsomething/src/libsomething_docs.xml $ mv libsomething/src/libgda_docs_override.xml libsomething/src/libsomething_docs_override.xml
A multiple-file renaming tool, such as prefixsuffix might help with this. We will provide the contents of these files later.
Note that files ending in .in will be used to generate files with the same name but without the .in suffix, by replacing some variables with actual values during the configure stage.
Now we edit the files to adapt them to to our needs. You might prefer to use a multiple-file search-replace too for this, such as regexxer.
For instance, in autogen.sh:
In configure.in (or configure.ac in newer projects),
Next we must adapt the various Makefile.am files:
We should now create our first .hg and .ccg files, to wrap one of the objects in the C library. We will delete any existing .hg and .ccg files:
$ rm -rf libexample/src/*.hg $ rm -rf libexample/src/*.ccg
and create new files:
$ touch libexample/src/thing.hg $ touch libexample/src/thing.ccg
We must mention all of our .hg and .ccg files in the libexample/src/Makefile_list_of_hg.am_fragment file, in the files_hg variable.
Any extra non-generated .h and .cc source files may be placed in libexample/libexamplemm/ and mentioned in libexample/libexamplemm/Makefile.am, in the files_extra_h and files_extra_cc variables.
In the .hg and .ccg files section you can learn about the syntax used in these files.