Re: [PATCH] perf jevents: Handle deleted JSONS in out of source builds

[Arnaldo Carvalho de Melo <acme@kernel.org>]

On Wed, Jan 21, 2026 at 09:51:30AM +0000, James Clark wrote:
> On 1/20/26 6:54 PM, Arnaldo Carvalho de Melo wrote:
> > On Tue, Jan 20, 2026 at 10:01:52AM -0800, Ian Rogers wrote:
> > > On Tue, Jan 20, 2026 at 7:39 AM James Clark <james.clark@linaro.org> wrote:
> > > > The cp command here doesn't remove files that have been removed from the
> > > > sourcetree. That means incremental builds can either succeed with stale
> > > > events or will fail completely if a stale json file has a broken
> > > > reference in it.

> > > > Fix it by using rsync instead of cp. legacy-cache.json has to be
> > > > excluded as this is a generated file isn't present in the source tree.

> > > > This only happens when deleting a JSON file, which has only happened
> > > > once since the linked commit. The fixes commit is marked as the origin
> > > > of the problem in case any future changes that delete JSONs are back
> > > > ported, rather than the first commit that deleted a JSON file.

> > > > Reported-by: Mark Brown <broonie@kernel.org>
> > > > Closes: https://lore.kernel.org/linux-next/aW5XSAo88_LBPSYI@sirena.org.uk/
> > > > Fixes: 4bb55de4ff03 ("perf jevents: Support copying the source json files to OUTPUT")
> > > > Signed-off-by: James Clark <james.clark@linaro.org>
> > > > ---
> > > > This is a bit of a hack and I thought that making jevents.py handle
> > > > multiple input folders would be a much better solution than this. Then
> > > > we could have "gen-pmu-events" for only generated files and "pmu-events"
> > > > for only in-tree input files. It would be very clear what's generated
> > > > and what's not and all copying rules and special clean rules just
> > > > disappear (and this isn't the first time these rules have caused build
> > > > issues).
> > > > 
> > > > Unfortunately, after a while of trying to modify the script I thought it
> > > > was too invasive for now. The script does output per-file at the very
> > > > bottom of the logic in process_one_file(), so adding files in another
> > > > folder ends up re-emitting section headers when another chunk is output.
> > > > Although other parts of the script do build things up in memory before
> > > > outputting so it was possible to make those parts work with multiple
> > > > folders transparently.
> > > 
> > > Thanks James!
> > > Acked-by: Ian Rogers <irogers@google.com>
> > > I see other rsync uses in:
> > > tools/testing/selftests/sparc64/Makefile
> > > tools/testing/selftests/bpf/Makefile
> > > but they aren't the most compelling mainstream uses. I wonder whether
> > > we can test for rsync's availability and if not fall back on cp?
 
> That will work if we completely wipe the destination directory every time.
> But it would be an untested path, because in reality everyone is going to
> have rsync. It might be better to re-implement rsync and then at least the
> same thing runs everywhere.
 
> > It is not mentioned at all in Documentation, so probably its best not to
> > add a requirement for it?
 
> I can hack together something that does the delete in a few lines of bash or
> make then? I did consider that originally but I thought that's what rsync
> does so I'll just use it.

Did this progress?

- Arnaldo