qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Stefan Hajnoczi <stefanha@gmail.com>
To: Alessandro Di Federico <ale@rev.ng>
Cc: qemu-devel@nongnu.org, Thomas Huth <thuth@redhat.com>,
	 Taylor Simpson <tsimpson@quicinc.com>,
	Anton Johansson <anjo@rev.ng>,
	philmd@linaro.org,  peter.maydell@linaro.org, bcain@quicinc.com,
	quic_mathbern@quicinc.com,  stefanha@redhat.com,
	Paolo Bonzini <pbonzini@redhat.com>
Subject: Re: [PATCH] Update scripts/meson-buildoptions.sh
Date: Tue, 3 Jan 2023 10:51:36 -0500	[thread overview]
Message-ID: <CAJSP0QUd9Q25pT3OXst4V-1FKLo65jJnn-6-7d_O5hkPeJfPyw@mail.gmail.com> (raw)
In-Reply-To: <20230103162603.74f631aa@orange>

On Tue, 3 Jan 2023 at 10:26, Alessandro Di Federico <ale@rev.ng> wrote:
>
> On Tue, 3 Jan 2023 09:37:51 -0500
> Stefan Hajnoczi <stefanha@gmail.com> wrote:
>
> > I don't understand the issue. Can you describe the steps that cause
> > meson-buildoptions.sh to become out-of-sync with meson_options.txt?
> >
> > This will continue to be a problem in the future. Is there a way to
> > fix it permanently?
>
> In Makefile we have:
>
>     $(SRC_PATH)/scripts/meson-buildoptions.sh:    $(SRC_PATH)/meson_options.txt
>
> (Cc'ing Paolo since he's the author of this line)
>
> This means make will regenerate
> `$(SRC_PATH)/scripts/meson-buildoptions.sh` if its last modification
> date is older than `$(SRC_PATH)/meson_options.txt`.
>
> However these files are in the source directory, so this will behave
> properly only under certain circumstances.
>
> For instance if, for some reason, someone committed a new version of
> `meson_options.txt` but not of `meson-buildoptions.sh`, a fresh clone
> of the repo will not have the dates set correctly to trigger the
> Makefile rule above:
>
>     $ ls -ln scripts/meson*
>     -rw-r--r-- 1 1000 1000 28913 Jan  3 15:58 scripts/meson-buildoptions.sh
>     -rw-r--r-- 1 1000 1000    91 Jan  3 15:58 scripts/meson.build
>
> This is because git does not update file dates depending on the last
> commit changing them.
>
> This, on top of the fact that invoking `ninja` does not trigger
> regeneration (which works for most other use cases), leads to a good
> chance of forgetting to update meson-buildoptions.sh.
>
> We could add the target to ninja to mitigate the risk, but still, the
> dates problem remains.
>
> An alternative solution would be to avoid committing generated files and
> simply regenerating it every time.
>
> On my machine `meson.py introspect --buildoptions` +
> `scripts/meson-buildoptions.py` take 1.070s.
> `./configure --help` takes 0.162s, so it's a bit sad.
> On the other hand an actual invocation of configure can take
> significantly longer (`./configure` takes 29.150s on my machine).
>
> To avoid re-running it every time we could invoke `make
> update-buildoptions` in `configure` but keep
> `scripts/meson-buildoptions.sh` in the build directory.

QEMU's Makefile used to a use a technique where it generated
"timestamp" files and used cmp(1) to check if rebuilding was
necessary:
1. Always generate meson-buildoptions.sh-timestamp.
2. If cmp meson-buildoptions.sh-timestamp meson-buildoptions.sh
detects a difference, cp meson-buildoptions.sh-timestamp
meson-buildoptions.sh.
3. Let make handle dependencies on meson-buildoptions.sh as usual.

You can find examples by grepping for -timestamp in the git log -p output.

I think this would solve the problem?

Stefan


  reply	other threads:[~2023-01-03 15:52 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 [this message]
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
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=CAJSP0QUd9Q25pT3OXst4V-1FKLo65jJnn-6-7d_O5hkPeJfPyw@mail.gmail.com \
    --to=stefanha@gmail.com \
    --cc=ale@rev.ng \
    --cc=anjo@rev.ng \
    --cc=bcain@quicinc.com \
    --cc=pbonzini@redhat.com \
    --cc=peter.maydell@linaro.org \
    --cc=philmd@linaro.org \
    --cc=qemu-devel@nongnu.org \
    --cc=quic_mathbern@quicinc.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).