[Spice-devel] repository reorg

[Alon Levy]

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

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

The rest of the repos will need to be updated. Concrete steps would be:

 (1) create spice/spice-common, spice/spice-server, spice/spice-client, spice/spice-gtk repositories (btw - any
 comments on the spice- prefix?)

 (2) get spice-common to build, the rest to use

 (3) remove the "spice/spice" repository

 (4) make spice-all

Comments?

> Ok, take two with Gerd's and Hans's and Uri's comments.
> 
>  (1) spice-protocol - keep it, move code generation stuff here
>  (spice_codegen.py, python_modules, spice*.proto), and have the dist tarball
>  contain the cpp and c files resulting from running it.
> 
>  (2) spice-server - new repo from spice/server, will submodule common. will
>  keep requiring spice-protocol as a separate entity, and will reference the c
>  files therein (does this make any sense, carrying c files as installed files?
>  I can't think of any other outcome of moving the codegen to spice-protocol)
> 
>  (3) spice-client - this will be the spice-gtk repo (or is anyone in favor of
>  keeping spice-gtk name?), and it will submodule common too.
> 
>  (4) common - submodule. easier to do cross changes with spice-server and spice-client,
>  dist tarballs package it (for spice-client, spice-server).
> 
>  And the rest don't require any changes:
> 
>   Rely just on spice-protocol, as before:
>    linux/vdagent
>    windows/vdagent
>    spice-xpi
>    spice-x
>    windows driver
>    linux driver
>   And these rely on spice-server, same as before
>    qemu
>    xspice
> 
> > 
> >  We currently have the following repositories:
> >   spice-protocol
> >   spice
> >   spice-gtk
> > 
> >  spice-protocol contains the following parts:
> >   qxl_dev.h - required by qemu and drivers
> >   controller.h - required by spice client and xpi/active-x
> >   the rest - protocol definitions for server and client
> >  
> >  spice is composed of
> >   codegen - generation of marshallers, demarshallers, and defines that go into spice-protocol.
> >   server - server implementation
> >   client - old client implementation
> >   common - shared by server and client, further subdivided to:
> >    glz/lz/quic encoders and decoders
> >    cache implementation
> >    canvas rendering implementation
> >    used by the server, old client and new client.
> >  
> >  Inefficiencies with the current repositories:
> >   1. updates to the protocol need to go to spice/spice.proto, run the codegen,
> >     and put the results to spice-protocol
> >   2. common exists in both spice and spice-gtk. since it hasn't been touched in
> >     a while it isn't a real problem, but still the code duplication is bad and
> >     in the future (3d canvas) it will be modified.
> > 
> >  Suggested changes:
> >   spice - merge spice-protocol into it
> >   spice-protocol - kill it
> >   common - extract to a separate library, it's own configure, pkg-config, name it spice-render,
> >    and have spice-gtk and spice (server and old client) rely on it.
> >   spice-gtk - keep it as is. easier to develop with a separate configure since it doesn't contain
> >   all the requirement checks for the server.
> > 
> >  Suggestion is Marc-Andre's but he didn't think it was important enough to discuss, I take
> >  responsibility for the time wasted as a result of this email.
> > 
> > Alon
> > _______________________________________________
> > Spice-devel mailing list
> > Spice-devel at lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/spice-devel
> _______________________________________________
> Spice-devel mailing list
> Spice-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/spice-devel