[Spice-devel] [PATCH spice-common] RFC: add back codegen

[Frediano Ziglio]

> 
> 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