On 11/5/2026 11:57 AM, Yonggang Luo wrote: > On Fri, Nov 6, 2026 at 3:53 AM Pierrick Bouvier > <[email protected]> wrote: >> >> On 11/5/2026 2:27 AM, Peter Maydell wrote: >>> On Tue, 3 Nov 2026 at 13:35, Paolo Bonzini <[email protected]> wrote: >>>> >>>> The following changes since commit >>>> 74f7bf4c59e6b6d50dbc6e124d93440be8be4386: >>>> >>>> Merge tag 'pull-target-arm-20261102-1' of https://gitlab.com/pm215/qemu >>>> into staging (2026-11-02 20:19:27 -0800) >>>> >>>> are available in the Git repository at: >>>> >>>> https://gitlab.com/bonzini/qemu.git tags/for-upstream >>>> >>>> for you to fetch changes up to ab78ac76f44a1241e76fd32d248df62d83f1ea58: >>>> >>>> meson: rewrite scripts/qemu-version.sh directly in meson.build >>>> (2026-11-03 14:31:24 +0100) >>>> >>>> ---------------------------------------------------------------- >>>> * target/i386/tcg: bugfixes and cleanups >>>> * AGENTS.md: add final instructions >>>> * meson: rewrite scripts/qemu-version.sh directly in meson.build >>>> >>>> ---------------------------------------------------------------- >>> >>> The qemu-version.h changes here seem to have broken incremental builds: >>> >>> In file included from ../../monitor/qmp-cmds-control.c:28: >>> /home/pm215/qemu/include/qemu/version.h:11:10: fatal error: >>> qemu-version.h: No such file or directory >>> 11 | #include "qemu-version.h" >>> | ^~~~~~~~~~~~~~~~ >>> compilation terminated. >>> >>> This happens even though the incremental rebuild decided it had >>> to re-run configure. >>> >>> Blowing away the build tree and doing a complete rebuild avoids the >>> error, but it would be nice for incremental builds to work. >>> >> >> It works fine on my side, with both ninja and make. qemu-version.h is >> correctly regenerated as the first target being executed. >> >> Can you reproduce this with a clean build folder? > > Hi, it's for incremental builds, that is a build (exists) before these > patches, > then reset hard to the version after this PR, then ninja will fail. > Clean build folder won't trigger issue. but for fast bisect, issues will > happen. >
I see, unfortunately there are multiple occurrences of such subtle breaking when moving between commits in our history already. Especially for current issue, it's now pushed and there, so we can't do anything to avoid bisect hitting this eventually. One nice and bulletproof solution is to rely on ccache, and allow ourselves to delete a build folder (a full ccache rebuild is less than 20 sec on my machine). > >> >>> thanks >>> -- PMM >>> >> >> > >
