GNOME Bugzilla – Bug 591138
g-c-c installs libslab library and headers, but no pkg-config file
Last modified: 2009-08-11 09:51:53 UTC
If g-c-c now ships all of libslab as a real library, then it should also distribute the pkg-config file.
Oh, and maybe bump the libslab soname if the API was changed ;-)
Also, the cflags are wrong: it's $includedir/libslab not $includedir/slab.
Created attachment 140194 [details] [review] Install libslab pkg-config file too
Created attachment 140195 [details] [review] Fix include directory in libslab pkg-config file
libslab is currently synched at release time, so any changes made to the g-c-c version will be overwritten.
(In reply to comment #5) > libslab is currently synched at release time, so any changes made to the g-c-c > version will be overwritten. Okay, we have a nice mess here :-) Apparently, there's now a real libslab tarball from a real libslab git module. Cosimo: what's the right thing to do? Shouldn't gnome-control-center drop its copy of libslab? And also, are you okay with the patches above? :-)
(In reply to comment #6) > Okay, we have a nice mess here :-) > > Apparently, there's now a real libslab tarball from a real libslab git module. > > Cosimo: what's the right thing to do? Shouldn't gnome-control-center drop its > copy of libslab? And also, are you okay with the patches above? :-) The right thing to do should be have g-c-c drop its internal libslab copy, and depend on the standalone library we created some time ago. Some time ago I published a branch for this here [1], and it works fine. It also drops a couple of obsolete/deprecated libraries. If g-c-c wants instead to go on shipping its own copy of libslab (which seems to be the direction some g-c-c maintainers want to go, at least for 2.28), then IMHO libslab should not be installed at all. [1] http://github.com/cosimoc/gnome-control-center/tree/dyn_libslab
(In reply to comment #7) > It also drops a couple of obsolete/deprecated libraries. I mean it drops the dependency on a couple of obsolete libraries :)
Created attachment 140207 [details] [review] Do not install libslab on the system
Here's a patch to keep the internal libslab but not install it on the system. (it also updates the code from the libslab module)
I am happy to have g-c-c depend on the external libslab, but many people from distros complained about it, so I guess it's safer if we keep the copy of libslab for 2.28 and move to the external one as soon as we branch for 2.30/3.0. What do you think? Also, changes in the g-c-c copy of libslab will get deleted whenever we copy next the external libslab, so we should probably have the external libslab provide, in libslab/Makefile.am, a way to not install the library at all, as we had before (ENABLE_DYNAMIC_LIBSLAB)
Okay, I went ahead and made the changes to libslab. I also updated the stuff in g-c-c too.