From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:48011) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Wi7lM-0004XJ-2j for qemu-devel@nongnu.org; Wed, 07 May 2014 15:44:25 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Wi7lG-0008IF-WC for qemu-devel@nongnu.org; Wed, 07 May 2014 15:44:20 -0400 Received: from mx1.redhat.com ([209.132.183.28]:16209) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Wi7lG-0008IB-PB for qemu-devel@nongnu.org; Wed, 07 May 2014 15:44:14 -0400 From: Markus Armbruster References: <20140502135218.31383.90270.stgit@fimbulvetr.bsc.es> <20140506130740.GA17717@irqsave.net> <20140506092725.4c195cbd@redhat.com> <5368F7F8.3090706@redhat.com> Date: Wed, 07 May 2014 21:44:06 +0200 In-Reply-To: <5368F7F8.3090706@redhat.com> (Eric Blake's message of "Tue, 06 May 2014 08:55:52 -0600") Message-ID: <87mwets7ax.fsf@blackfin.pond.sub.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH v12 0/4] qapi: Allow modularization of QAPI schema files List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eric Blake Cc: =?utf-8?Q?Beno=C3=AEt?= Canet , qemu-devel@nongnu.org, =?utf-8?Q?Llu=C3=ADs?= Vilanova , Luiz Capitulino Eric Blake writes: > On 05/06/2014 07:27 AM, Luiz Capitulino wrote: >> On Tue, 6 May 2014 15:07:40 +0200 >> Beno=C3=AEt Canet wrote: >>=20 >>> 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 stu= ff. >>> >>> 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 f= ile ?) >>=20 >> 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 mast= er >> 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=C3=AEt, Llu=C3=ADs, would either of you be willing to tackle this?