Hi,
On 06/23/2011 12:18 PM, Alon Levy wrote:
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.
I think it would be best to only have qxldev + agent + controller headers here,
and have a real spice-common library which would also contain the .proto file,
generator and have compiled marshaller code end up inside the spice-common.so.0
file. IOW common would have anything common between the server and any
client(s).
So:
-.proto
-code generator
-the rendered
And the generated .so would contain both the render and the marshaller code,
since
both sides will need these both.
(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)
See above, having a proper common for protocol + render stuff would avoid the
need for ugly hacks with installing C-files.
(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).
I would rather see common become a proper lib..
Regards,
Hans
_______________________________________________
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel
