ObjGTKGen is a utility that generates Objective-C language bindings for GNOME GLib/Gobject based libraries using GObject Introspection (GOI), which it does by parsing GIR files.
objgtkgen currently is meant to be run within a local directory like the one given in this repository. Next to the binary it expects a
Config dir containing the two files provided and it is going put its output into a directory specified in
Run it like so:
This will generate the library definition for GTK3 into the output dir, including all the library dependencies specified by
The generator is going to lookup these dependencies recursively at the path of the gir file specified as argument. You may exclude library and class dependencies of each library by modifying
Dependencies and building
- You need ObjFW.
- The GIR files required for your library. You may generate them manually, but the easiest way usually is to use those provided by your Linux distribution. F.e. for Debian and GTK3 use
apt install gir1.2-gtk-3.0
- see packages starting with
gir1.2for further library introspection provided by Debian you may use to generate ObjC/ObjFW bindings
- see packages starting with
- For building a generated library you need OGObject.
chmod +x autogen.sh && ./autogen.sh && ./configure && make
ObjGTKGen is free software. Its source files Tyler Burton originally released under GNU LGPL 2.1 or later. This licensing was kept for the files existing and for the directory LibrarySourceAdditions, which is meant to be part of the generated libraries and is NOT part of the generator.
In consent with Tyler Burton the generator itself is released under GNU GPL 3.0 or later.
Regarding GTK3 (and 4 or any other library wrapper) the generator is meant to generate wrapper source files which may be distributed under LGPL 2.1 or later.
The code base of ObjGTK should be compatible with the Objective C dialect of GCC ("Objective C 2.0") as introduced as of Mac OS X 10.5. So there should be no need to use clang. There are plans to implement advanced support of clang language features, especially memory management via Automatic Reference Counting (ARC).
Currently there are only untested, unstable preview releases of ObjGTK. Take care when using. API is going to change. See milestones for the further release plan.
How it works
The generator does the following currently:
XMLReaderit parses a GIR file (.gir) into object instances of the GIR classes (see directory
src/GIR) (source models)
Gir2Objcthen maps the information of the GIR models into the models prefixed with
src/Generator) (target models). Please note that these models still hold API/class informationen using C names and types as used by the Glib/GObject libraries. These models provide methods to transform their Glib ("c") data/names/types into Objective C classes/names/types.
- It does the same for further libraries iterating recursively through all the libraries specified as dependencies by the gir file given.
- When all library and class definitions are held in memory necessary to resolve class dependencies correctly using
OGTKLibraryWriteris called to first invoke
OGTKClassWriteris going to write out the ObjC class definitions. It does so by resolving GObject types to Objective C / OGTK types (swapping them) using the class mappings and definitions hold in multiple
- When all classes are written, additional manual source files, that may be added at
LibrarySourceAdditionsare added to
Output(the generated library) to actually make it compile and run. Please note the classes at
LibrarySourceAdditionsare not part of the generator itself. You may add your own code by creating new directories which naming convention needs to meet that of the corresponding gir file.
You will find the main business logik preparing data structures in
OGTKMapper for multiple loops through all the parsed (Gobj) class/API information to complete dependency information (naming of parent classes) and the dependency graph (parent classes, depending classes). This is necessary to correctly insert
@class statements when generating the ObjC class definitions without getting stuck in a circular dependency loop.
For the actual generation and composition of the source files see