[Spice-devel] repository reorg

Alon Levy alevy at redhat.com
Tue Jun 28 03:26:18 PDT 2011


On Thu, Jun 23, 2011 at 04:25:34PM +0300, Uri Lublin wrote:
> On 06/23/2011 02:10 PM, Alon Levy wrote:
> >On Thu, Jun 23, 2011 at 12:18:11PM +0200, Alon Levy wrote:
> >>On Wed, Jun 22, 2011 at 05:00:10PM +0200, Alon Levy wrote:
> >>>Hi All,
> >>
> >
> >Ok, so take three:
> >
> >  (1) spice-protocol - remains unchanged. specifically, despite the name, will
> >   not contain the .proto nor the python codegen bits nor the generated files.
> >
> >  (2) spice-common (repository spice/common) - new repository, contains:
> >   spice*.proto
> >   spice_codegen.py and friends (python_modules subdir)
> >   produces a proper shared library, used by spice-server, spice-client, spice-gtk, named
> >   libspice-common.so.0, containing marshalling and rendering code (including any decoder/encoder)
> >   plus anything else currently in common (like ssl-verify).
> 
> I think making libspice-common.so.0 will take (a bit) more work than
> initially expected. Note that both server/ and client/ source files
> #include .c files of common/ .
> 
> 
> >
> >  (3) spice-client - breakoff client subdir from current spice (maybe rename+remove-the-rest to keep history)
> >
> >  (4) spice-server - rename current spice repo (just to keep history)
> >
> >  (5) spice-gtk - remains, just move it to freedesktop now that we want to keep it.
> >
> >  (6) spice-all - convenience repository that has the rest as submodules and has a helpful makefile to build them all.
> >
> 
> Lots of git repos.
> 
> Just a quick history scan:
> 0.2 -- one git to rule them all (and one big tarball)
> 0.4 -- a single git for server,client,common (without qxl, spicex)
>        split tarballs --> ability to generate 3 different
>                           tarballs for server,client,common
> 0.6 -- a single tarball + introducing spice-protocol
> * spice-gtk repo created
> 0.8 -- similar to 0.6
> 0.10 -- splitting into 6 git repos (?).

I guess a spice-all that would actually be useful would counteract this tendency.

I'm going along with suggestion 3+, where spice-common is a submodule, not a library.

> 
> _______________________________________________
> Spice-devel mailing list
> Spice-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/spice-devel


More information about the Spice-devel mailing list