From: Paolo Bonzini <pbonzini@redhat.com>
To: Stefan Hajnoczi <stefanha@gmail.com>,
Peter Maydell <peter.maydell@linaro.org>
Cc: Alessandro Di Federico <ale@rev.ng>,
qemu-devel@nongnu.org, Thomas Huth <thuth@redhat.com>,
Taylor Simpson <tsimpson@quicinc.com>,
Anton Johansson <anjo@rev.ng>,
philmd@linaro.org, bcain@quicinc.com, quic_mathbern@quicinc.com,
stefanha@redhat.com
Subject: Re: [PATCH] Update scripts/meson-buildoptions.sh
Date: Sat, 7 Jan 2023 19:02:37 +0100 [thread overview]
Message-ID: <8cf1e1ee-1e2a-d53f-3f8c-e870fe51f75d@redhat.com> (raw)
In-Reply-To: <CAJSP0QUWxTbpyfuQhKQ33BKHKOWTTMrCo5QASSqjag9wz9a=gA@mail.gmail.com>
On 1/3/23 20:31, Stefan Hajnoczi wrote:
>> The other problem with this file is that it appears to
>> be generated differently depending on the host distro
>> (specifically the default value for the --libdir option).
>> That also would seem to nudge towards "don't commit a
>> generated file".
I wasn't aware of the libdir default that Peter mentioned, but the same
issue would happen for release tarballs so "do not commit it" would have
to be extended to "do not ship it", that is do everything in Python.
This in turn goes back to the reason for the buildoptions.sh approach:
the path to the Python binary is not known when "configure --help"
prints the help message. If the user does not have a python3 or meson
binary in the path, requiring "configure --meson=... --help" or
"configure --python=... --help" is not hideous I guess, but not pretty
either.
> Paolo: Is the meson-buildoptions.sh approach a temporary solution or
> something long-term? Maybe everything can be migrated to meson
> eventually so that ./configure and meson-buildoptions.sh are no longer
> necessary?
It is long-term. Meson is only used to build the emulators and that
part will move entirely out of configure soon, but other parts of the
build (especially tests/tcg and firmware, which need to build docker
containers for cross-compilation) are separate and there's no plan to
use anything but configure/Makefile for the overall orchestration.
While I have noticed stale meson-buildoptions.sh it's never happened to
me. I ascribed it to someone not noticing the dirty file rather than a
bug; it should be possible to add a test to CI that catches it.
Paolo
next prev parent reply other threads:[~2023-01-07 18:03 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-02 10:41 [PATCH] Update scripts/meson-buildoptions.sh Alessandro Di Federico via
2023-01-03 14:14 ` Thomas Huth
2023-01-03 14:37 ` Stefan Hajnoczi
2023-01-03 15:26 ` Alessandro Di Federico via
2023-01-03 15:51 ` Stefan Hajnoczi
2023-01-03 16:11 ` Alessandro Di Federico via
2023-01-03 17:30 ` Peter Maydell
2023-01-03 19:31 ` Stefan Hajnoczi
2023-01-07 18:02 ` Paolo Bonzini [this message]
2023-01-09 1:59 ` Richard Henderson
2023-01-04 14:39 ` Stefan Hajnoczi
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=8cf1e1ee-1e2a-d53f-3f8c-e870fe51f75d@redhat.com \
--to=pbonzini@redhat.com \
--cc=ale@rev.ng \
--cc=anjo@rev.ng \
--cc=bcain@quicinc.com \
--cc=peter.maydell@linaro.org \
--cc=philmd@linaro.org \
--cc=qemu-devel@nongnu.org \
--cc=quic_mathbern@quicinc.com \
--cc=stefanha@gmail.com \
--cc=stefanha@redhat.com \
--cc=thuth@redhat.com \
--cc=tsimpson@quicinc.com \
/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).