On Wed, Dec 03, 2014 at 12:42:03PM -0500, Marc-André Lureau wrote: > hi > > ----- Original Message ----- > > Hey, this patch series refactors the content of configure.ac of spice-common, > > and > > makes a few cleanups of Makefile.am. The reason for these changes is that I'd > > like to > > introduce a SPICE_COMMON_SETUP m4 macro which could be used by > > spice-gtk/spice-server > > to setup the spice-common build tree without invoking spice-common/configure. > > It would > > also be possible to call this macro from the current configure.ac coming with > > spice-common > > so that it can be made standalone in the future. > > It is already standalone. It would be nice to keep it that way. It's not a separate module with its own tarball and releases installing its own shared library to $libdir. This is what I meant here by standalone. My message is explaining that I'm planning to keep the current status quo (ie keep a working configure.ac in spice-common to have a starting point when someone wants to make it standalone). > > > > > It also removes spice-protocol as a submodule, which means you need to 'make > > install' it after making some changes. As spice-protocol is an API stable > > module with regular upstream releases, I think it's better not to ship a > > random snapshot of it with spice-server/spice-gtk releases. > > That's pretty annoying, since as you said it is a stable module, > _every change_ would deserve a release in order to be useful in any of > the Spice projects. There's a change every few months in spice-protocol, so yeah, before making a release of spice-server/spice-gtk which uses new features from spice-protocol, we'd need to make a release. This is how it already works for vd_agent and the qxl driver. > > What is the problem you are trying to solve by removing submodule? I > remember it install the protocol files, but noone reported bugs. This > is probably something that can be fixed instead. > > I would rather keep spice-protocol as a submodule because it is > actually convenient when you are accustomed to it Well, this is more or less a respin of an old series, which was NACK'ed but where you said: « http://lists.freedesktop.org/archives/spice-devel/2013-November/015329.html > This also removes spice-protocol as a submodule, it's a standalone module > with its own releases, so we can depend on it instead. However, I agree with that. » From my perspective, managing submodule within submodule isn't convenient at all, running 3 autogen.sh/configure in a row every time you need to run configure is not efficient at all. Moreover, code bundling is frowned upon by distributions ( https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries ), even though the spice-protocol situation is a bit borderline here. But in general, moving from duplicating the spice-protocol code in multiple tarballs to having one reference tarball is a move in the right direction. Christophe
Attachment:
pgpHi1JHrPNhh.pgp
Description: PGP signature
_______________________________________________ Spice-devel mailing list Spice-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/spice-devel