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

[Marc-André Lureau]

Hi

On Wed, Mar 9, 2016 at 2:12 PM, Christophe Fergeau <cfergeau at redhat.com> wrote:
> Hey,
>

Thanks for the reply, I was chomping at the bit! I can't wait for releases.

> On Fri, Feb 26, 2016 at 06:37:59PM +0100, Marc-André Lureau wrote:
>> codegen generated code depends on spice-common code (marshaller, messages etc),
>
> The code generated by the python scripts indeed depends on
> spice-common/common/messages.h and
> spice-common/common/client_marshallers.h

and other code from spice-common, you cannot link without all that.

> However, I think that these patches are moving us from one suboptimal
> situation to a similarly suboptimal situation, just one which is less
> broken release-wise. We've got a module named spice-protocol, but it
> does not contain the protocol description, the protocol description is
> duplicated in spice-gtk and spice-server instead. Moreover,

At the source level it's only in spice-common though. I don't see a
problem duplicating it in tarball (same as other utility scripts etc).
Furthemore, a lot of projects duplicate a protocol header/common
definition in their project for simplicity, because protocols are
stable, and because C is not the only language.

> spice-protocol still contains this enums.h header which is
> auto-generated from the same python scripts. I assume with that proposal
> this is going to need to be manually sync'ed?

Yes. fwiw, I always thought of enums.h as a file we need to maintain
manually but that can be generated (similar to symbol files).

> 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. Imho, if you go that road, we better merge
spice-proto & common.

> Another option might be to ship a libspice-marshaller.so with
> spice-protocol, but I haven't looked how realistic that is.
> Maybe there are other options, maybe there is strong disagreement with
> having spice.proto/the code gen bits in spice-protocol, we can discuss
> all of this now ;)

No strong disagreement, but I think having code for
marshalling/demarshalling is very implementation specific and is a
better fit for a spice-common library (submodule today).

In the meantime, I would welcome either Pavel or this revert so we can
proceed with releases.

thanks

-- 
Marc-André Lureau