Re: [Tracker] Incomplete introspection data for libtracker-sparql

[Sam Thursfield <ssssam gmail com>]

On Thu, Mar 30, 2017 at 11:20 PM, Sam Thursfield <ssssam gmail com> wrote:
> Hi
> While doing the Meson conversion I noticed the GObject-introspection
> data for libtracker-sparql is actually incomplete. We use the valac
> `--gir` option to generate it, which means that the C parts
> (tracker-resource and tracker-notifier mainly) are missed out.

I had a look at solving this at the weekend. I didn't finish anything
but I tried out two approaches, both of which look possible.

First I tried running g-ir-scanner across all the .c and .h files,
including those generated by Vala. I hit these issues:

  * #line directives triggering a bug in g-ir-scanner:
https://bugzilla.gnome.org/show_bug.cgi?id=781354
  * documentation comments in some of the .vala code required some
(transfer) and (element-type) annotations adding to them.
  * warnings from g-ir-scanner about the internal _construct()
functions that `valac` generates for each object -- those aren't
declared static but also have no introspection annotations. The
warnings cause g-ir-scanner to hide those symbols which is what we
want to happen.
 * link errors from g-ir-scanner's build against
tracker_sparql_connection_get().

The last issue is a pain, it requires that we either move the
introspection scanning to src/libtracker-sparql-backend, or create a
stub library containing a tracker_sparql_connection_get() symbol that
we only pass to g-ir-scanner. It's pretty horrible to do the
introspection scanning in a different directory to where the library
is built, purely because libtracker-sparql-backend/Makefile.am can't
access any vars from libtracker-sparql/Makefile.am so we have to
maintain the list of source files in both places. A stub library seems
a lot more practical.

This approach would be a bit tricky for the Meson build rules to
handle because it doesn't give us a way to access the Vala-generated
.c files. We could probably modify Meson's gnome.generate_gir()
function to let us pass .vala files to it though and have that code
resolve them to their .c output files.


There's a second approach which seems cleaner to me if it works. We
can continue to generate a .gir from the Vala code using `valac
--gir`, generate a separate .gir file from the bits of
libtracker-sparql that are written in C, then pass both to
`g-ir-compiler` to create a single .typelib.

There are two blockers to this approach. One is that g-ir-compiler
currently only processes the first .gir file passed into it. It's
actually pretty simple to merge to .gir files into one ourselves,
they're just XML documents so a 20 line Python script can do the job.

The second problem is that `valac` is quite strict about the name of
the .gir file it generates. In fact if we run `valac --gir
Tracker_Vala-1.0.gir` then it creates a .gir with a namespace of
Tracker_Vala, which is totally wrong. It may be possible to get away
with having Tracker-1.0.gir and Tracker_C-1.0.gir (for the C parts),
but if we need to merge both those into a file that also has to be
called Tracker-1.0.gir then the Make rules become nightmarish.

At this point I ran out of time for now. I'm interested in trying the
second approach a bit further and perhaps seeing if we can add support
for merging multiple .gir files together in g-ir-compiler. That would
take some work though, while the first approach could probably be
finished off in a few hours.

I guess a third option is to rewrite the Vala bits in C or the C bits
in Vala. However, the Vala code has quite a lot of GIO async
functions, which are really long-winded to write in C. While the C
code has a bunch of macro-generated functions
(tracker_resource_set/get_xxx) which would have to be a mass of
copy-paste code if rewritten in Vala.

I'm interested on hearing other people's thoughts on this!
Sam