GNOME Bugzilla – Bug 730615
a11y private library not included in GIR
Last modified: 2014-06-03 08:49:24 UTC
Created attachment 277029 [details] [review] a11y: build directly into libgtk instead of an internal library The stuff in gtk/a11y/*.{c,h} is currently not included in the GIR. IMHO the easiest way to include it is to just build it directly into libgtk (like the deprecated subdirectory is). It would also be possible to keep the current structure by duplicating the lists of C sources and headers from gtk/a11y/Makefile.am in gtk/Makefile.am, but I don't see an advantage, so the attached patch just does away with the internal library. Note that I have no idea what is going on with the VS project stuff—someone else will have to take a look at that to make sure I didn't break anything.
I don't follow - nothing in gtk/a11y is public api; it has no place in the gir
actually, I was wrong, we do keep the a11y headers in there.
But I still don't like the approach. Introspection needs to be able to deal with real-existing build setups, not constantly force everybody to rewrite their headers, rewrite their apis, and change their build setups.
to be fair, the gtk build set up is an horrific hodgepodge of internal libraries and recursive Makefiles; on top of that, libtool makes everything more complicated than it needs be. if we're compiling the a11y symbols unconditionally into our shared object, going through a separate, noinst library is just pointless churn; I'd drop that (and a lot more stuff) even if we didn't want to build introspection data. on this particular instance, it should not be necessary to rejig the build system; if we want, we should be able to generate the introspection data using libgtk3.0.so as the shared object, and the accessibility headers and C files as the source files for the introspection scanner to parse. we used to do something like that for Clutter, before ditching the recursive Makefile build.
(In reply to comment #4) > on this particular instance, it should not be necessary to rejig the build > system; if we want, we should be able to generate the introspection data using > libgtk3.0.so as the shared object, and the accessibility headers and C files as > the source files for the introspection scanner to parse. we used to do > something like that for Clutter, before ditching the recursive Makefile build. I'm not really sure what you're proposing here... where would this list of accessibility headers and C files be? AFAICT the only choices are 1) Keep things as they are, introspection consumers don't get to use this API. 2) Drop the internal library, which is what my patch did. 3) Create a copy of the lists of a11y headers and C sources in gtk/Makefile.am to pass to g-ir-scanner. FWIW, when I filed this I thought it was a blocker for transitioning the Vala bindings to G-I, but I now see that we never actually included gtk-a11y.h so the existing bindings could never have worked (unless someone passed -include gtk-a11y.h to the CC without reporting the bug to us, in which case I kind of feel like they deserve for their build to break), so I'm okay with #1--I'll just drop the relevant code from the Vala bindings.
Attachment 277029 [details] pushed as 4a4b23b - a11y: build directly into libgtk instead of an internal library
Hi Evan, > Note that I have no idea what is going on with the VS project stuff—someone > else will have to take a look at that to make sure I didn't break anything. Thanks for getting most of the needed updates for the VS files done, I have completed one last part for that[1]. With blessings, thank you! [1]: Commit 48533b7b.