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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.