Hi ----- Original Message ----- > On Wed, Mar 09, 2016 at 03:02:53PM +0100, Marc-André Lureau wrote: > > > Longer term, I think it should be possible to autogenerate > > > common/messages.h > > > and common/client_marshallers.h as well, which hopefully would avoid > > > the issue we currently have. I have some hackish code which generates a > > > correct common/client_marshallers.h file already, I haven't looked at > > > common/messages.h yet. > > > > That wouldn't solve it all, you would still need spice-common for the > > rest of the code to link. > > spice-protocol does not ship any generated file( apart from enums.h), > nor try to use this generated code. It ships the .proto file and the .py > files, and then spice-common calls spice-codegen.py in order to generate > the file it needs to parse spice-protocol. to generate code that needs spice-common (what an imbroglio) spice-protocol should remain code-less imho. Just declarations. (and should be fine to copy (or submodule) given its stability contract) The generator is too specific to the spice-common code. > > 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? _______________________________________________ Spice-devel mailing list Spice-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/spice-devel