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

Marc-André Lureau mlureau at redhat.com
Wed Mar 9 16:56:59 UTC 2016


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?


More information about the Spice-devel mailing list