Re: [Qemu-devel] [PATCH v12 0/4] qapi: Allow modularization of QAPI schema files

["Benoît Canet" <benoit.canet@irqsave.net>]

The Wednesday 07 May 2014 à 21:44:06 (+0200), Markus Armbruster wrote :
> Eric Blake <eblake@redhat.com> writes:
> 
> > On 05/06/2014 07:27 AM, Luiz Capitulino wrote:
> >> On Tue, 6 May 2014 15:07:40 +0200
> >> Benoît Canet <benoit.canet@irqsave.net> wrote:
> >> 
> >>> I am trying to use this series to modularise the block API.
> >>>
> >>> Here are my finding.
> >>>
> >>> I tried to make a qmp/block.json including VM state related API.
> >>> block.json include a qmp/block-core.json containing only true block stuff.
> >>>
> >>> When generating and compiling block-core.json to link it with qemu-nbd
> >>> I saw that some of the block stuff needed ErrorClass so I went the route
> >>> of creating a qmp/common.json containing ErrorClass.
> >>>
> >>> common.json being included in block-core.json and in qapi-schema.json it
> >>> quickly lead some code being generated in double and the
> >>> compilation to choke.
> >>>
> >>> What do you think would be the best solution to fix this ?
> >>> (Fix the generator ? Make include ignore second inclusion of the same file ?)
> >> 
> >> Make qapi-schema.json a sort of master file and include everything?
> >
> > Won't cut it, if we want to support a subset of files in other contexts.
> >  You either have to do:
> >
> > qemu-schema.json:
> >   include common
> >   include block
> >   include other
> >
> > qemu-block:
> >   include common
> >   include block
> >
> > where block does not work in isolation, and has to be wrapped; but now
> > we have two different wrappers depending on the two different clients
> > that want a different subset.
> 
> Won't win beauty contests, but it isn't exactly terrible, either.
> 
> >                                Or you do:
> >
> > qemu-schema.json:
> >   include common
> >   include block
> >   include other
> > block.json:
> >   include common
> >
> > now block.json is standalone, and qemu-schema.json ends up including
> > common through two different paths.
> 
> Yes.
> 
> >> Eventually, we might want to have if/defs and whatnot. But having a master
> >> file seems a reasonable first step to me. I actually thought this was the
> >> intention. Unless I got it wrong, of course.
> >
> > Ifdefs may be a bit much.  If we add them, then we can worry about
> > explicit include guards, the same as the C preprocessor.  But for now,
> > I'd be perfectly fine with a followup patch that includes a file's
> > contents exactly once, no matter how many times it is included (that is,
> > act as if include guards were implicitly present, since we lack
> > conditionals, so include files are currently idempotent).
> 
> As long as the meaning of an include doesn't depend on its environment
> (and I don't see that change for QAPI schemata), making the include
> idempotent is the right thing.
> 
> Benoît, Lluís, would either of you be willing to tackle this?

I need it badly I will do it.

Best regards

Benoît

>