Browse thread
[Caml-list] [ANN] ocaml-gir: automated binding generator
- Adrien
[
Home
]
[ Index:
by date
|
by threads
]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
| Date: | -- (:) |
| From: | Adrien <camaradetux@g...> |
| Subject: | [Caml-list] [ANN] ocaml-gir: automated binding generator |
I'm pleased to announce a preview release of ocaml-gir. ocaml-gir is an automated binding generator for glib-based libraries. It works by parsing the output of gobject-introspection[0] which in turn works by parsing header files. gobject-introspection doesn't work on preprocessed sources and is able to take advantage of the glib-style C macros to improve the library interface description. It is currently in alpha/beta stage and is able to bind most of WebKit-gtk and DBus-GLib and both are working here. Other libraries are *partially* supported (i.e. gcc finds errors in the C code). The description of the libraries is often broken because of gobject-introspection itself (it strips out GError** paramaters...) or incomplete because of a lack of annotations. ocaml-gir is hosted on the ocamlcore forge[1] using git and its sources are accessible through git-web[2]. A tarball is also available[3]. ocaml-gir ships with the .gir/.xml files generated by this tool and modified to fix various errors, expand annotations or improve the caml-side api (only once right now). Therefore, trying to use gobject-introspection to generate the description again is not advised. There is README explaining quickly how to use ocaml-gir in the source folder. Compared to camlidl, its main advantage is to work on .h files rather than on .idl ones. My first motivation for ocaml-gir was to get webkit-gtk. I knew its API was changing often and I didn't feel like checking everything every few weeks. Another difference is that ocaml-gir tries to follow lablgtk's API style. For example, it uses polymorphic variants to bind C enums. Moreover, I wasnt't sure how camlidl was going to handle structs named like WebKitWebView which ocaml type should be web_view. However ocaml-gir probably has a ton of bugs and isn't complete yet (the api exposed will change a bit and every "feature" isn't bound). Also, one has to keep in mind automated binding generation from C isn't magic. An int* could be an int array or an out-parameter and int** or int*** would be even more annoying to deal with. It requires source-code annotations. A language with an actual array type and richer types, with functions able to easily return several values and with exceptions may not need them. [0] http://live.gnome.org/GObjectIntrospection [1] https://forge.ocamlcore.org/projects/ocaml-gir/ [2] http://git.ocamlcore.org/cgi-bin/gitweb.cgi?p=ocaml-gir/ocaml-gir.git [3] https://forge.ocamlcore.org/frs/download.php/286/ocaml-gir-preview.tar.gz --- Adrien Nader