Re: [PATCH v4 2/3] tools build: Avoid circular .fixdep-in.o.cmd issues

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

On Fri, Jul 19, 2024 at 11:32:08AM -0700, Andrii Nakryiko wrote:
> On Tue, Jul 16, 2024 at 12:55 AM Jiri Olsa <olsajiri@gmail.com> wrote:
> >
> > On Mon, Jul 15, 2024 at 01:32:43PM -0700, Brian Norris wrote:
> > > The 'fixdep' tool is used to post-process dependency files for various
> > > reasons, and it runs after every object file generation command. This
> > > even includes 'fixdep' itself.
> > >
> > > In Kbuild, this isn't actually a problem, because it uses a single
> > > command to generate fixdep (a compile-and-link command on fixdep.c), and
> > > afterward runs the fixdep command on the accompanying .fixdep.cmd file.
> > >
> > > In tools/ builds (which notably is maintained separately from Kbuild),
> > > fixdep is generated in several phases:
> > >
> > >  1. fixdep.c -> fixdep-in.o
> > >  2. fixdep-in.o -> fixdep
> > >
> > > Thus, fixdep is not available in the post-processing for step 1, and
> > > instead, we generate .cmd files that look like:
> > >
> > >   ## from tools/objtool/libsubcmd/.fixdep.o.cmd
> > >   # cannot find fixdep (/path/to/linux/tools/objtool/libsubcmd//fixdep)
> > >   [...]
> > >
> > > These invalid .cmd files are benign in some respects, but cause problems
> > > in others (such as the linked reports).
> > >
> > > Because the tools/ build system is rather complicated in its own right
> > > (and pointedly different than Kbuild), I choose to simply open-code the
> > > rule for building fixdep, and avoid the recursive-make indirection that
> > > produces the problem in the first place.
> > >
> > > Link: https://lore.kernel.org/all/Zk-C5Eg84yt6_nml@google.com/
> > > Signed-off-by: Brian Norris <briannorris@chromium.org>
> > > ---
> > >
> > > (no changes since v3)
> > >
> > > Changes in v3:
> > >  - Drop unnecessary tools/build/Build
> >
> > Acked-by: Jiri Olsa <jolsa@kernel.org>
> >
> > so usually Arnaldo takes changes for tools/build, Arnaldo, could you please take a look?
> > but still there'are the tools/lib/bpf bits..
> 
> I think it should be fine for libbpf bits to go through Arnaldo's tree
> and get back to bpf-next eventually. Unlikely that we'll have any
> conflict in libbpf's Makefile specifically, we rarely change it.

I got this series now in perf-tools-next,

Thanks,

- Arnaldo