From: Brian Norris <briannorris@chromium.org>
To: Masahiro Yamada <masahiroy@kernel.org>
Cc: Bjorn Helgaas <helgaas@kernel.org>,
linux-kbuild@vger.kernel.org,
Josh Poimboeuf <jpoimboe@kernel.org>,
Peter Zijlstra <peterz@infradead.org>
Subject: Re: possible dependency error?
Date: Tue, 18 Jun 2024 16:29:28 -0700 [thread overview]
Message-ID: <ZnIYWBgrJ-IJtqK8@google.com> (raw)
In-Reply-To: <CAK7LNASrR2W-obUurSWaKLnQ+CB1o9iuoaM-hbHnv-zoazMzmQ@mail.gmail.com>
Hi Masahiro,
Thanks for the reply. I've been away for a bit, but I've poked at a few
more things now.
On Sun, May 26, 2024 at 01:35:43AM +0900, Masahiro Yamada wrote:
> On Fri, May 24, 2024 at 2:54 AM Brian Norris <briannorris@chromium.org> wrote:
> > --- a/tools/lib/subcmd/Makefile
> > +++ b/tools/lib/subcmd/Makefile
> > @@ -76,7 +76,7 @@ include $(srctree)/tools/build/Makefile.include
> >
> > all: fixdep $(LIBFILE)
> >
> > -$(SUBCMD_IN): FORCE
> > +$(SUBCMD_IN): fixdep FORCE
> > @$(MAKE) $(build)=libsubcmd
> >
> > $(LIBFILE): $(SUBCMD_IN)
>
>
>
> I may not fully understand the design policy of the tools/ build system,
> but this fix is presumably correct because the 'fixdep' binary
> is needed in each sub-directory for it to work correctly.
>
> tools/bpf/resolve_btfids/libsubcmd/.exec-cmd.o.cmd must
> be generated by tools/bpf/resolve_btfids/libsubcmd/fixdep
> instead of by tools/bpf/resolve_btfids/fixdep.
>
> But, fixing tools/lib/subcmd/Makefile is not enough.
>
> *.cmd files under tools/bpf/resolve_btfids/libbpf/staticobjs/
> are broken for the same reason.
> So, this is fundamentally broken in many places.
I think I hacked something that works there too. It gets a bit uglier,
but not too bad IMO.
> And, as you noted, there is no easy way to fix .fixdep.o.cmd
I haven't come up with a *great* solution, but I came up with something
that works for the most part, by circumventing the normal Build /
Makefile.build split. It's getting pretty ugly too though...
> Your description in
> https://issuetracker.google.com/issues/313508829#comment32
> is all correct.
>
>
> "can we just use Kbuild?" is a good question.
> I do not understand why they use fragile build systems,
> where obviously they cannot do it correctly.
>
>
> In fact, I submitted a patch to migrate objtool to Kbuild
> because that fixes all the issues cleanly.
>
> The objtool maintainers rejected it.
> https://lore.kernel.org/linux-kbuild/1551764896-8453-3-git-send-email-yamada.masahiro@socionext.com/
>
>
> Not only the build system.
> He also refused to participate in the standard Documentation
> directory.
> tools/objtool/Documentation/objtool.txt still resides in its own directory.
While I don't love having to solve the same problems repeatedly (once in
Kbuild; potentially-many in tools/), I'm also OK with trying to hack
fixes into the current duplicate build system if it's not prohibitively
complex to do so.
Here's what I have for now -- I might submit some or all of this as a
proper patchset if I can fix a few rough edges.
diff --git a/tools/build/Makefile b/tools/build/Makefile
index 17cdf01e29a0..fad93f64035d 100644
--- a/tools/build/Makefile
+++ b/tools/build/Makefile
@@ -43,11 +43,8 @@ ifneq ($(wildcard $(TMP_O)),)
$(Q)$(MAKE) -C feature OUTPUT=$(TMP_O) clean >/dev/null
endif
-$(OUTPUT)fixdep-in.o: FORCE
- $(Q)$(MAKE) $(build)=fixdep
-
-$(OUTPUT)fixdep: $(OUTPUT)fixdep-in.o
- $(QUIET_LINK)$(HOSTCC) $(KBUILD_HOSTLDFLAGS) -o $@ $<
+$(OUTPUT)fixdep: $(srctree)/tools/build/fixdep.c
+ $(QUIET_CC)$(HOSTCC) $(KBUILD_HOSTLDFLAGS) -o $@ $<
FORCE:
diff --git a/tools/build/Makefile.include b/tools/build/Makefile.include
index 8dadaa0fbb43..27b2090cb293 100644
--- a/tools/build/Makefile.include
+++ b/tools/build/Makefile.include
@@ -1,8 +1,16 @@
# SPDX-License-Identifier: GPL-2.0-only
build := -f $(srctree)/tools/build/Makefile.build dir=. obj
+# More than just $(Q), we sometimes want to suppress all command output from a
+# recursive make -- even the 'up to date' printout.
+ifeq ($(V),1)
+ SILENT_MAKE = $(Q)$(MAKE)
+else
+ SILENT_MAKE = $(Q)$(MAKE) --silent
+endif
+
fixdep:
- $(Q)$(MAKE) -C $(srctree)/tools/build CFLAGS= LDFLAGS= $(OUTPUT)fixdep
+ $(SILENT_MAKE) -C $(srctree)/tools/build CFLAGS= LDFLAGS= $(OUTPUT)fixdep
fixdep-clean:
$(Q)$(MAKE) -C $(srctree)/tools/build clean
diff --git a/tools/lib/bpf/Makefile b/tools/lib/bpf/Makefile
index 2cf892774346..a8f34de1ca25 100644
--- a/tools/lib/bpf/Makefile
+++ b/tools/lib/bpf/Makefile
@@ -154,6 +154,8 @@ $(BPF_IN_SHARED): force $(BPF_GENERATED)
$(Q)$(MAKE) $(build)=libbpf OUTPUT=$(SHARED_OBJDIR) CFLAGS="$(CFLAGS) $(SHLIB_FLAGS)"
$(BPF_IN_STATIC): force $(BPF_GENERATED)
+ $(call rule_mkdir)
+ $(SILENT_MAKE) -C $(srctree)/tools/build CFLAGS= LDFLAGS= OUTPUT=$(STATIC_OBJDIR) $(STATIC_OBJDIR)fixdep
$(Q)$(MAKE) $(build)=libbpf OUTPUT=$(STATIC_OBJDIR)
$(BPF_HELPER_DEFS): $(srctree)/tools/include/uapi/linux/bpf.h
diff --git a/tools/lib/subcmd/Makefile b/tools/lib/subcmd/Makefile
index b87213263a5e..59b09f280e49 100644
--- a/tools/lib/subcmd/Makefile
+++ b/tools/lib/subcmd/Makefile
@@ -76,7 +76,7 @@ include $(srctree)/tools/build/Makefile.include
all: fixdep $(LIBFILE)
-$(SUBCMD_IN): FORCE
+$(SUBCMD_IN): fixdep FORCE
@$(MAKE) $(build)=libsubcmd
$(LIBFILE): $(SUBCMD_IN)
next prev parent reply other threads:[~2024-06-18 23:29 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-17 23:27 possible dependency error? Bjorn Helgaas
2023-05-18 8:26 ` Masahiro Yamada
2024-05-23 17:54 ` Brian Norris
2024-05-25 16:35 ` Masahiro Yamada
2024-06-18 23:29 ` Brian Norris [this message]
2024-06-19 6:02 ` Masahiro Yamada
2024-07-02 0:37 ` Brian Norris
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=ZnIYWBgrJ-IJtqK8@google.com \
--to=briannorris@chromium.org \
--cc=helgaas@kernel.org \
--cc=jpoimboe@kernel.org \
--cc=linux-kbuild@vger.kernel.org \
--cc=masahiroy@kernel.org \
--cc=peterz@infradead.org \
/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