On Thu, Mar 30, 2017 at 11:20 PM, Sam Thursfield <sss...@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 _______________________________________________ tracker-list mailing list tracker-list@gnome.org https://mail.gnome.org/mailman/listinfo/tracker-list
