Thinking of glib's GObject (and) Introspection API

Milan Crha mcrha at redhat.com
Tue Apr 26 05:05:30 PDT 2016


On Mon, 2016-02-22 at 08:05 +0100, Milan Crha wrote:
> I can look on it.

	Hi,
I've an initial patch for the inclusion of the libical-glib in the
libical sources. You can find the zipped patch here:
    https://people.gnome.org/~mcrha/libical-glib/
The patch file is ~700KB large after unpacking, but it's due to added
files, not due to changed files. The final folder structure changed
too, from the proposal I made earlier. The patch can be applied using
`git am file.patch`. I didn't want to attach it here due to the size of
it, even the packed size is 1/10 of the original file.

I confess I'm new to CMake, thus it can be that some changes I made are
not correct, inefficient and so on, thus feel free to suggest better
ways of achieving the same.

The patch works similarly as the libical-glib upstream (at GNOME git),
which is: the libical-glib source files are generated from provided API
files, then a library is built. From this library are generated
introspection bindings and new tests had been added to test this
introspection as well. These tests are part of "make test". Finally,
from the source files is created developer documentation using gtk-doc. 
This documentation is installed into the place where DevHelp can find
it. The doc/reference/libical-glib/CMakeLists.txt contains a comment
how to generate libical-glib-docs.xml.in, which can be done from
sources when the new API is added or some removed.

The API files, stored at src/libical-glib/api/ contains the libical API
description with comments and other necessary data for both the
documentation and the introspection. Any API change in the libical
should be also propagated into the API files.

I expect some follow-up changes being done in the libical-glib code,
but these might be some minor performance tweaks, compiler warning
fixes and similar, nothing review-blocking, as far as I can tell. I've
got a promise from Miao Yu, that these will be provided within the next
two weeks. I do not see any problem in applying those changes to the
libical separately, but if you'd prefer to wait for it, then I'm fine
with it too. As those will be only source changes, the main review
process on the CMake related files and the way I chose to do this all
can be reviewed and discussed meanwhile.

By the way, the libical-glib introspection API is more complete and
fine tuned, thus I'd even think of removing the actual introspection
libical code in favour of the libical-glib. Similar with the
documentation.

The libical-glib is built by default, because I would like to use it in
other projects (evolution-data-server as the one of them) in the
future, thus it'll be better to have it built by default and disabled
only if the distribution maintainers would like to disable it for
whatever reason (I cannot see any reason right now, maybe except of
"it's new and not used yet").

Please, let me know your opinion, ideas and so on.
	Thanks and bye,
	Milan




More information about the libical-devel mailing list