[Spice-devel] repository reorg

[Alon Levy]

On Wed, Jun 22, 2011 at 05:00:10PM +0200, Alon Levy wrote:
> Hi All,

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