> > 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. > Yes, unless we manage to have generator more generic and less spice-dependent but this would require a different project and a kind of protocol-generator project. Not something we are addressing or even plannes. > > > 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. 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. The "spice-protocol" repository name is quite misleading as it contains only part of the protocol as spice.proto is big part of the protocol but it's hard to have it separate from spice-common. If generator code could generate everything from spice(1).proto we could leave spice(1).proto in spice-protocol and have everything really protocol related in spice-protocol but it's not easy to get it. Still we would have the problem of manual copy and where to put the python code. Frediano _______________________________________________ Spice-devel mailing list Spice-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/spice-devel