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

[Marc-André Lureau]

----- Original Message -----
> 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.

yes, and it's a pain for adding features to the agent, or building on windows. I would rather have spice-protocol has submodule there (I actually had branches doing that for easing my pain, but I don't deal too much with those anymore)

> 
> > 
> > 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

We will have to disagree, submodules are convenient once your wrap your head around it (just like many other git concepts). That's the reason why we use them in the first place.

I really don't think we need to argument configure-time speed. If you are after that, we are better off just removing autofoo.

> 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.
> 

And yet bundling is more and more common: the distro model is not such a panacea  (no need to list all projects doing that one way or another). And in the case of spice modules, there isn't much to "share" in common packages.