On Wed, Mar 09, 2016 at 12:21:38PM -0500, Frediano Ziglio wrote: > > > > Imho, if you go that road, we better merge spice-proto & common. > > > > > > Having a small 'spice-protocol parsing' library is probably better than > > > spice-common calling code generation scripts shipped by spice-protocol > > > indeed. I don't think the canvas/ssl/... code currently in spice-common > > > would make sense in spice-protocol though. > > > > I don't follow your reasoning. spice-common is common code for various C > > spice code. It doesn't matter if they also share ssl or canvas handling, or > > does it? > > I think what Christophe was trying to say is that canvas code surely > should not be moved in spice-protocol. Yes exactly. > However IMHO spice-protocol files would make sense in spice-common > repository. > > I honestly won't dislike to have spice-protocol be just a package > generated by spice-common code and spice-common a repository. > That is removing spice-protocol repository and putting everything in > spice-common. > It would solve the manual copy of enums.h too. Do you mean that 'make dist' in spice-common would generate a spice-protocol tarball with the same content as today? I don't know how hard to do this would be, but that's an interesting idea... Might be a bit weird to have to clone spice-common and make install there to build the QXL driver while having this as a spice-server submodule at the same time. Christophe
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ Spice-devel mailing list Spice-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/spice-devel