[Spice-devel] repository reorg
alevy at redhat.com
Wed Jun 22 11:01:19 PDT 2011
On Wed, Jun 22, 2011 at 08:14:57PM +0300, Uri Lublin wrote:
> On 06/22/2011 06:00 PM, Alon Levy wrote:
> >Hi All,
> > We currently have the following repositories:
> > spice-protocol
> > spice
> > spice-gtk
> spice-vdagent (for both Windows and Linux)
> spice-xpi/active-x (as mentioned below)
> > 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
> What will you do with other components that require spice-protocol,
> such as spice-vdagent.
we will still package spice-protocol as an rpm, and if you want to build from git
you would just make install the server instead of the spice-protocol.
> > 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.
> Many times changes in "common/" files come with changes in "server/"
> or "client/" files (for example, adding a parameter to an existing
> function, or adding a new function). So we're back to committing
> into two repositories (plus synchronizing their versions).
> Maybe using git magic is a better solution (?).
> Specifically I'm thinking of "git submodule", but there may be a better way.
I don't know what is better :( I'm ok with having a git submodule for common.
> Spice-devel mailing list
> Spice-devel at lists.freedesktop.org
More information about the Spice-devel