Hi,
(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.
Compile them into a small shared library?
(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)
I wouldn't use submodules like this. Better make common/ a real shared
library which can be compiled + installed on its own.
(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.
I'd keep the spice-gtk name, it is more than just a client.
It also leaves the spice-client name for the old one and probably
reduces confusion as we have spice-client packages with the old client
today.
We might add a spice-all repo which has just all the other stuff as
submodules and some makefile glue to build everything in the correct
order. As pure convinience thing.
cheers,
Gerd
_______________________________________________
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel
