From: "Daniel P. Berrange" <berrange@redhat.com>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: "Lluís Vilanova" <vilanova@ac.upc.edu>,
"QEMU Developers" <qemu-devel@nongnu.org>,
"Michael Roth" <mdroth@linux.vnet.ibm.com>,
"Markus Armbruster" <armbru@redhat.com>
Subject: Re: [Qemu-devel] [PATCH ] [trivial] qapi: Build-depend on all json files
Date: Thu, 4 Feb 2016 15:44:25 +0000 [thread overview]
Message-ID: <20160204154425.GY30301@redhat.com> (raw)
In-Reply-To: <CAFEAcA8MubjT7kthNDmHtz==P+DrBs2q08rDAZq9zZDWBad49w@mail.gmail.com>
On Thu, Feb 04, 2016 at 03:36:56PM +0000, Peter Maydell wrote:
> On 4 February 2016 at 15:32, Eric Blake <eblake@redhat.com> wrote:
> > On 02/04/2016 07:55 AM, Peter Maydell wrote:
> >> On 4 February 2016 at 14:39, Lluís Vilanova <vilanova@ac.upc.edu> wrote:
> >>> Dynamically detects the files used to generate QAPI code, thus ensuring
> >>> it's never out of sync with the sources.
> >>>
> >>> Signed-off-by: Lluís Vilanova <vilanova@ac.upc.edu>
> >>> ---
> >>> Makefile | 6 ++----
> >>> 1 file changed, 2 insertions(+), 4 deletions(-)
> >>>
> >>> diff --git a/Makefile b/Makefile
> >>> index d0de2d4..627f772 100644
> >>> --- a/Makefile
> >>> +++ b/Makefile
> >>> @@ -269,10 +269,8 @@ $(SRC_PATH)/qga/qapi-schema.json $(SRC_PATH)/scripts/qapi-commands.py $(qapi-py)
> >>> $(gen-out-type) -o qga/qapi-generated -p "qga-" $<, \
> >>> " GEN $@")
> >>>
> >>> -qapi-modules = $(SRC_PATH)/qapi-schema.json $(SRC_PATH)/qapi/common.json \
> >>> - $(SRC_PATH)/qapi/block.json $(SRC_PATH)/qapi/block-core.json \
> >>> - $(SRC_PATH)/qapi/event.json $(SRC_PATH)/qapi/introspect.json \
> >>> - $(SRC_PATH)/qapi/crypto.json
> >>> +qapi-modules = $(SRC_PATH)/qapi-schema.json
> >>> +qapi-modules += $(shell find $(SRC_PATH)/qapi -name "*.json")
> >>
> >> All the .json files are in the same directory, so I don't think we should
> >> need to use find here. Does
> >>
> >> qapi-modules += $(wildcard $(SRC_PATH)/qapi/*.json))
> >>
> >> work ?
> >
> > Does this wildcard affect what goes into a tarball? I'm worried that we
> > may run the risk of a stale .json file on one developer's machine
> > causing an unreproducible build on other machines where the file is not
> > found; explicit lists tend to be safer than wildcards.
> >
> > I won't reject the patch if others like it, but I won't approve it myself.
>
> You need to ask Mike Roth about our tarball generation process, not me.
>
> I do agree that this patch needs to make the case for why .json source
> files are special and should be wildcarded, when for instance all our
> C source files are explicitly listed in makefiles.
Yes, normal practice is that the files are listed in a Makefile that lives
in the same dir as the file. The qapi json files are not following that
since they live in a dir above. I'd be inclined to say any patch should
take us in line with source files, and thus look more like this:
diff --git a/Makefile b/Makefile
index b7b0f24..5481b57 100644
--- a/Makefile
+++ b/Makefile
@@ -161,7 +161,8 @@ dummy := $(call unnest-vars,, \
qom-obj-y \
io-obj-y \
common-obj-y \
- common-obj-m)
+ common-obj-m \
+ qapi-modules)
ifneq ($(wildcard config-host.mak),)
include $(SRC_PATH)/tests/Makefile
@@ -269,10 +270,7 @@ $(SRC_PATH)/qga/qapi-schema.json $(SRC_PATH)/scripts/qapi-commands.py $(qapi-py)
$(gen-out-type) -o qga/qapi-generated -p "qga-" $<, \
" GEN $@")
-qapi-modules = $(SRC_PATH)/qapi-schema.json $(SRC_PATH)/qapi/common.json \
- $(SRC_PATH)/qapi/block.json $(SRC_PATH)/qapi/block-core.json \
- $(SRC_PATH)/qapi/event.json $(SRC_PATH)/qapi/introspect.json \
- $(SRC_PATH)/qapi/crypto.json
+qapi-modules += $(SRC_PATH)/qapi-schema.json
qapi-types.c qapi-types.h :\
$(qapi-modules) $(SRC_PATH)/scripts/qapi-types.py $(qapi-py)
diff --git a/qapi/Makefile.objs b/qapi/Makefile.objs
index 2278970..a644a69 100644
--- a/qapi/Makefile.objs
+++ b/qapi/Makefile.objs
@@ -4,3 +4,10 @@ util-obj-y += string-input-visitor.o string-output-visitor.o
util-obj-y += opts-visitor.o
util-obj-y += qmp-event.o
util-obj-y += qapi-util.o
+
+qapi-modules += common.json
+qapi-modules += block.json
+qapi-modules += block-core.json
+qapi-modules += event.json
+qapi-modules += introspect.json
+qapi-modules += crypto.json
NB, this is completely untested - i just hacked the makefile for purpose
of illustration.
Regards,
Daniel
--
|: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org -o- http://virt-manager.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
next prev parent reply other threads:[~2016-02-04 15:44 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-04 14:39 [Qemu-devel] [PATCH ] [trivial] qapi: Build-depend on all json files Lluís Vilanova
2016-02-04 14:55 ` Peter Maydell
2016-02-04 15:32 ` Eric Blake
2016-02-04 15:36 ` Peter Maydell
2016-02-04 15:44 ` Daniel P. Berrange [this message]
2016-02-04 16:34 ` Lluís Vilanova
2016-02-04 18:23 ` Lluís Vilanova
2016-02-04 16:31 ` Lluís Vilanova
2016-02-04 15:58 ` Lluís Vilanova
2016-02-04 14:58 ` Lluís Vilanova
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160204154425.GY30301@redhat.com \
--to=berrange@redhat.com \
--cc=armbru@redhat.com \
--cc=mdroth@linux.vnet.ibm.com \
--cc=peter.maydell@linaro.org \
--cc=qemu-devel@nongnu.org \
--cc=vilanova@ac.upc.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).