Thinking of glib's GObject (and) Introspection API

[Allen Winter]

On Tuesday, April 26, 2016 02:05:30 PM Milan Crha wrote:
> 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/
Great!
I created a new branch off master called glib and applied your patch there
for testing and cleaning.  The patch applied flawlessly.

> 
> 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.
> 
Right. I haven't looked too closely yet.

> 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").
> 
Probably have to turn it off on Windows by default.
Anyway to quiet all those "Warning: multiple "IDs" for constraint linkend: foo" messages?


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