(In reply to comment #0)
> 10:59 < smcv> treitter_, pwithnall: why does tp-glib install its .vapi/.deps in 
>               $prefix/share/telepathy/vapi/telepathy-glib.vapi?
> 10:59 < smcv> treitter_, pwithnall: every other .vapi in Debian seems to be in 
>               /usr/share/vala/vapi
> 10:59 < pwithnall> smcv: I don't know; the usual place is 
>                    $prefix/share/vala/vapi
> 11:00 < pwithnall> I was guessing it's because they're not particularly stable
> 11:02 < smcv> wouldn't it be better to use telepathy-glib-experimental.vapi or 
>               something, and knock off the -experimental suffix when it's 
>               considered stable?
> 11:03 < pwithnall> smcv: Or telepathy-glib-0.0.vapi, yes, probably
> 11:03 < pwithnall> Have to see what treitter_ says
> 11:03 < smcv> well the problem with that is if you have more than 11 
>               experimental versions, the .vapi version gets larger than the 
>               real version :-)
> 11:04 < smcv> you can't parallel-install two versions anyway though, because 
>               each tp-glib version corresponds to exactly one vapi version, and 
>               different telepathy-glib versions aren't parallel-installable
> 11:05 < smcv> so there's not much point in versioning the .vapi until tp-glib 
>               breaks ABI

Vala strictly ties the pkgconfig name to its "package name" elsewhere. So including one Vala package while building another requires "--pkg foo", which looks for foo.pc (to get the proper compiler and linker flags to use after generating the C code) and looks for foo.vapi to satisfy mappings between Vala and C symbols.

So I don't think we have much leeway in renaming telepathy-glib.vapi.

> Offering a .pc file to put the vapi directory onto the path seems to be highly
> unconventional (I haven't seen any evidence of it in Debian), so if there's a
> compelling reason to do this, it should be documented somewhere.

I thought it would be handy to confirm at configure-time whether the telepathy-glib Vala bindings are installed. But it looks like we can just check for the file in $(pkg-config --variable=vapidir vala-1.0). So we can just cut the telepathy-glib.pc file.

I've done that in this new branch. Please review and if you approve. I bump the nano version so libfolks can depend upon this version.

(The corresponding libfolks branch is http://git.collabora.co.uk/?p=user/treitter/folks.git;a=shortlog;h=refs/heads/tp-glib-vala-packaging - we'll need to merge this as soon as the tp-glib fix is in place. We'd need a lot of short-lived build cruft to be fully backwards-compatible here.)

(In reply to comment #1)
> > Offering a .pc file to put the vapi directory onto the path seems to be highly
> > unconventional (I haven't seen any evidence of it in Debian), so if there's a
> > compelling reason to do this, it should be documented somewhere.
> 
> I thought it would be handy to confirm at configure-time whether the
> telepathy-glib Vala bindings are installed. But it looks like we can just check
> for the file in $(pkg-config --variable=vapidir vala-1.0). So we can just cut
> the telepathy-glib.pc file.
> 
> I've done that in this new branch. Please review and if you approve. I bump the
> nano version so libfolks can depend upon this version.

> -m4_define([tp_glib_nano_version], [1])
> +m4_define([tp_glib_nano_version], [2])

I'd prefer not to have libfolks depend on an unreleased telepathy-glib. We can do that without adding extra cruft, by doing the telepathy-glib change in two stages:

* change telepathy-glib to install in the normal vapidir, but still install telepathy-vala.pc, with the following change:

-vapidir=@datadir@/telepathy/vapi
-valaflags=--vapidir=${vapidir}
+vapidir=@datadir@/vala/vapi
+valaflags=

* (time passes)

* release telepathy-glib 0.11.11 with that change, which does not break the existing libfolks

* in libfolks git, bump the dependency to 0.11.11 and make it ignore telepathy-vala.pc

* (time passes)

* release libfolks 0.1.n with that change

* delete telepathy-vala.pc

(In reply to comment #2)
> (In reply to comment #1)
> > > Offering a .pc file to put the vapi directory onto the path seems to be highly
> > > unconventional (I haven't seen any evidence of it in Debian), so if there's a
> > > compelling reason to do this, it should be documented somewhere.
> > 
> > I thought it would be handy to confirm at configure-time whether the
> > telepathy-glib Vala bindings are installed. But it looks like we can just check
> > for the file in $(pkg-config --variable=vapidir vala-1.0). So we can just cut
> > the telepathy-glib.pc file.
> > 
> > I've done that in this new branch. Please review and if you approve. I bump the
> > nano version so libfolks can depend upon this version.
> 
> > -m4_define([tp_glib_nano_version], [1])
> > +m4_define([tp_glib_nano_version], [2])
> 
> I'd prefer not to have libfolks depend on an unreleased telepathy-glib. We can
> do that without adding extra cruft, by doing the telepathy-glib change in two
> stages:
> 
> * change telepathy-glib to install in the normal vapidir, but still install
> telepathy-vala.pc, with the following change:
> 
> -vapidir=@datadir@/telepathy/vapi
> -valaflags=--vapidir=${vapidir}
> +vapidir=@datadir@/vala/vapi
> +valaflags=

Good idea - I've done this in the new branch vala-packaging1. I'll finish up the rest of the procedure in a new branch after 0.11.11 is released.

Looks good; please merge, but then leave this bug open, retitled to "delete telepathy-vala.pc when a libfolks release stops using it".

(In reply to comment #4)
> Looks good; please merge, but then leave this bug open, retitled to "delete
> telepathy-vala.pc when a libfolks release stops using it".

I timed out and merged this, since I'd like to do a tp-glib release today.

Blocked by GNOME bug 625928.

(In reply to comment #6)
> Blocked by GNOME bug 625928.

No longer blocked, as that's now fixed. Please delete telepathy-vala.pc in master.

Removed in http://git.collabora.co.uk/?p=user/cassidy/telepathy-glib;a=shortlog;h=refs/heads/vala

Ship it.

Merged, will be in 0.11.13