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

[Marc-André Lureau]

Hi

----- Original Message -----
> Well, from my side, the reason we started using them is because they
> _seemed_ convenient (not much experience with submodules back in the
> days), and after a while, they don't seem that convenient to me. Maybe
> I failed at wrapping my head properly around them (I tried different
> things in the past), in which case a description of your setup/workflow
> may be useful.

- branch the module and submodule for the feature X
- properly track submodule for changes just like any other change in the repo
- make sure to run autogen or git submodule update when switching branches (this is usually the "pain" people have with git submodule because they are lazy and assume that git checkout will do it for you, I think).
- if needed, in order to share the protocol changes, I use a "common" spice-protocol with the features branch, as a remote for the submodules, ex:
 ~/src/spice-protocol (the common repo)
  virgl
  mime-clipboard
 ~/src/spice-{gtk/server}/spice-common/spice-protocol
  remotes/dev/virgl
  remotes/dev/mime-clipboard 

I hope that helps

> > I really don't think we need to argument configure-time speed. If you
> > are after that, we are better off just removing autofoo.
> 
> Well, I'm not suggesting something that drastic ;) Not running
> spice-protocol configure every time is an easy win without making huge
> changes to what we have now.

I am not sure, I don't know what you have in mind to remove autoconf subdir for the moment.

Btw, you can use configure subdir cache to speed up configure-time, since some checks are repeated. I haven't tried, but it will surely give you the boost you are after.

> > > 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.
> 
> All spice modules share the protocol definition, so it sounds better to
> have that in one module with well defined releases which they all depend
> on, rather than having each module using a specific version of the
> protocol. There really is no need to bundle it, apart from lazyness on
> our side.

To me, the protocol in master is stable, so each change deserver a release. So in practice, tracking a git reference is the same as depending on a release tarball. It is less convenient and flexible, making development of branches more difficult imho.

If you want to work on an unstable feature, you should use feature branches of the protocol, or explicitly mark your protocol addition as experimental (like the webdav channel: changes are always possible, ex deprecate a channel, we better avoid them for compatibility reasons).