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 > > also > 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. > Uri. > > _______________________________________________ > Spice-devel mailing list > Spice-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/spice-devel _______________________________________________ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
