telepathy doesn't build if I disable introspection because telepathy-glib.vapi depends on introspection: Making all in vala make[2]: Entering directory `/home/kmaraas/src/gnome/telepathy-glib-0.11.14/vala' make[2]: *** No rule to make target `../telepathy-glib/TelepathyGLib-0.12.gir', needed by `telepathy-glib.vapi'. Stop. make[2]: Leaving directory `/home/kmaraas/src/gnome/telepathy-glib-0.11.14/vala' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/kmaraas/src/gnome/telepathy-glib-0.11.14'
You can't enable the Vala bindings if you've disabled introspection. I'll add a check for this in configure.ac.
Fixed in git for 0.11.15
I tried 0.11.15 and got the following error with introspection enabled: Making all in vala make[2]: Entering directory `/home/kmaraas/src/gnome/telepathy-glib-0.11.15/vala' /opt/gnome2/bin/vapigen \ --library telepathy-glib \ --pkg gio-2.0 \ ../telepathy-glib/TelepathyGLib-0.12.gir \ ** (vapigen:19811): CRITICAL **: vala_gir_parser_parse_type_from_name: assertion `type_name != NULL' failed ** (vapigen:19811): CRITICAL **: vala_code_node_set_parent_node: assertion `self != NULL' failed TelepathyGLib-0.12.gir:13.7-13.28: error: expected end element of `alias' TelepathyGLib-0.12.gir:13.7-13.28: error: expected end element of `namespace' TelepathyGLib-0.12.gir:14.5-14.4: error: expected end element of `repository' Generation failed: 3 error(s), 0 warning(s) make[2]: *** [telepathy-glib.vapi] Error 1 make[2]: Leaving directory `/home/kmaraas/src/gnome/telepathy-glib-0.11.15/vala' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/kmaraas/src/gnome/telepathy-glib-0.11.15' make: *** [all] Error 2 *** Error during phase build of telepathy-glib: ########## Error running make *** [1/1]
Travis is looking into it. It seems g-i 0.9.5 changed the format of its .gir files, so Vala can no longer interpret them.
This is the in-progress branch for Vala to fix compilation: http://git.gnome.org/browse/vala/log/?h=0.10-gir However, as of this writing, it introduces a bug or two (all the TpIntset functions are directly below TelepathyGLib instead of being inside TelepathyGLib.Intset). Furthermore, g-i 0.9.5 is more aggressive in the way it labels symbols as introspection=0 (which vapigen just skips over, as it should). For example, we get these warnings for Channel:group-members-changed-detailed which result in it being skipped: <unknown>:: Warning: TelepathyGLib: (Signal)group-members-changed-detailed: argument object: Unresolved type: 'GArray_guint_' <unknown>:: Warning: TelepathyGLib: (Signal)group-members-changed-detailed: argument p0: Unresolved type: 'GArray_guint_' <unknown>:: Warning: TelepathyGLib: (Signal)group-members-changed-detailed: argument p1: Unresolved type: 'GArray_guint_' <unknown>:: Warning: TelepathyGLib: (Signal)group-members-changed-detailed: argument p2: Unresolved type: 'GArray_guint_' <unknown>:: Warning: TelepathyGLib: (Signal)group-members-changed-detailed: argument p3: Unresolved type: 'GHashTable_gchararray+GValue_' We have annotations for the element types, and they worked with g-i 0.9.3. So, of course, these missing symbols mean that Folks won't build. And it's probably true of other downstream code, since Channel:group-members-changed-detailed is pretty key.
The latest version of g-i from git fixes the element type errors, but still has this: * TelepathyGLib.ConnectionRequestHandlesCb.handles does not point to .n_handles as its length parameter The remaining problems are in the Vala branch: * all the TpIntset functions are directly below TelepathyGLib instead of being inside TelepathyGLib.Intset
http://git.collabora.co.uk/?p=user/treitter/telepathy-glib.git;a=shortlog;h=refs/heads/g-i-fixes We also need these trivial annotation changes. They should be completely safe for g-i <= 0.9.5 as well.
(In reply to comment #7) > We also need these trivial annotation changes. They should be completely safe > for g-i <= 0.9.5 as well. Commit c78a2f2742d2e looks fine, please merge but leave this bug open for now.
(In reply to comment #6) > The latest version of g-i from git fixes the element type errors, but still has > this: > > * TelepathyGLib.ConnectionRequestHandlesCb.handles does not point to .n_handles > as its length parameter This seems to be a problem with _all_ relevant callback typedefs. Another problem with them is that in the GIR file, their c:types are all in the namespace "TelepathyGLib", rather than "Tp". > The remaining problems are in the Vala branch: > > * all the TpIntset functions are directly below TelepathyGLib instead of being > inside TelepathyGLib.Intset Looks like a g-ir-scanner problem to me, since it's also a problem in the GIR file. It might be because the type is TpIntSet, but the methods are prefixed tp_intset_ (rather than tp_int_set_; note the capitalisation of the type).
Here's a branch to rename TpIntSet to TpIntset, and thus appease g-ir-scanner. This works, but then vapigen breaks on the <alias/> element in the GIR. Filed as: https://bugzilla.gnome.org/show_bug.cgi?id=629649. http://git.collabora.co.uk/?p=user/pwith/telepathy-glib;a=shortlog;h=refs/heads/30134-intset-rename
> - * TpIntSet: > + * TpIntset: > * > * Opaque type representing a set of unsigned integers. Please add something like "Before 0.11.UNRELEASED this type was called TpIntSet, which is now a backwards-compatible typedef." Likewise for TpIntsetFastIter and TpIntsetIter. I suspect you also need to patch the docs' sections.txt to pick up the new names instead of the old. Please make check with gtk-doc enabled.
http://git.collabora.co.uk/?p=user/pwith/telepathy-glib;a=shortlog;h=refs/heads/30134-intset-rename Attempt 2, now with fixed docs and (skip) annotations on the backwards-compatibility typedefs, as suggested in bgo#629649. Since we haven't made any guarantees about our GIR or VAPI stability, we're at liberty to not include the backwards-compatibility aliases in the GIR. This saves us waiting on the Vala bug, bgo#629649. However, I've come up against the problem that g-ir-scanner isn't paying attention to the (skip) annotations for TpIntSet, TpIntSetIter and TpIntSetFastIter; so this branch is now pending on bgo#629668.
Sorry, the branch URI should've been: http://git.collabora.co.uk/?p=user/pwith/telepathy-glib;a=shortlog;h=refs/heads/30134-intset-rename-attempt2.
I've merged my trivial branch (Philip's branch still remains): commit 7c3c2066999eb2741f2880fa5120365d95ddb956 Author: Travis Reitter <travis.reitter@collabora.co.uk> Date: Mon Sep 13 16:49:32 2010 -0700 Explicitly annotate asv helper functions' out parameters as such. gobject-introspection < 0.9.5 automatically detected these, but >= 0.9.5 is more strict. telepathy-glib/dbus.c | 22 +++++++++++----------- 1 files changed, 11 insertions(+), 11 deletions(-)
r+ for Philip's branch, although I'd have preferred appended patches relative to what I previously reviewed.
Patch merged for 0.11.16 or 0.12.0, whichever happens next.
One major remaining problem with the GIR file is that the documentation comments for callback types don't seem to be being used, with the consequence that their annotations aren't applied. Filed as https://bugzilla.gnome.org/show_bug.cgi?id=629683.
That's been fixed, and the GIR file now seems good enough for libfolks to compile, modulo some Vala problems. They may be masking some more tp-glib GIR problems though. Branch with a small annotation addition which I found necessary: http://git.collabora.co.uk/?p=user/pwith/telepathy-glib;a=shortlog;h=refs/heads/30134-trivial-annotations
(In reply to comment #18) > Branch with a small annotation addition which I found necessary: > http://git.collabora.co.uk/?p=user/pwith/telepathy-glib;a=shortlog;h=refs/heads/30134-trivial-annotations Cherry-picked, thanks; will be in 0.11.16.
Note that, to build the Vala bindings, we'll also need to bump our requirements: vala >= 0.9.9 gobject-introspection >= 0.9.6
(In reply to comment #20) > Note that, to build the Vala bindings, we'll also need to bump our > requirements: > > vala >= 0.9.9 > gobject-introspection >= 0.9.6 I was under the impression the situation was more like: you need one of * g-i >= 0.9.6 and vala >= 0.9.9 * g-i < 0.9.5 and vala >= 0.9.8 which isn't really the same thing (for a start, it lets you build on current versions of many distributions). We could make that check explicit, with the former recommended, perhaps.
(In reply to comment #21) > (In reply to comment #20) > > Note that, to build the Vala bindings, we'll also need to bump our > > requirements: > > > > vala >= 0.9.9 > > gobject-introspection >= 0.9.6 > > I was under the impression the situation was more like: you need one of > > * g-i >= 0.9.6 and vala >= 0.9.9 > * g-i < 0.9.5 and vala >= 0.9.8 > > which isn't really the same thing (for a start, it lets you build on current > versions of many distributions). We could make that check explicit, with the > former recommended, perhaps. Yeah, I guess we can do that at the autotools level, and let distros package it to require whichever of the two works with their available packages.
So, it looks like we're down to the following requirements for this bug: * a bug fix for bgo#629649 * the release of gobject-introspection 0.9.6 * the release of vala 0.9.9 (assuming it includes the fix for bgo#629649) * adding the build requirements to tp-glib: (g-i >= 0.9.6 && vala >= 0.9.9) || (g-i < 0.9.5 && vala >= 0.9.8)
(In reply to comment #23) > * adding the build requirements to tp-glib: > (g-i >= 0.9.6 && vala >= 0.9.9) || > (g-i < 0.9.5 && vala >= 0.9.8) Since older vala breaks libfolks, I just made --enable-vala-bindings depend on g-i 0.9.6 and vala 0.10.0. Fixed in 0.12.0.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.