[Spice-devel] [spice-common 00/13] Improvements to spice-common configure.ac/Makefile.am

[Christophe Fergeau]

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





-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/spice-devel/attachments/20141204/2388e5b8/attachment.sig>