[Spice-devel] repository reorg
alevy at redhat.com
Thu Jun 23 04:10:01 PDT 2011
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_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
> 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:
> windows driver
> linux driver
> And these rely on spice-server, same as before
> > 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
More information about the Spice-devel