From: Markus Mayer via buildroot <buildroot@buildroot.org>
To: Buildroot Mailing List <buildroot@buildroot.org>
Cc: Markus Mayer <markus.mayer@broadcom.com>
Subject: [Buildroot] [PATCH v2] package/linux-tools/linux-tool-perf.mk.in: fix doc build issue
Date: Thu, 15 Oct 2026 15:29:05 -0700 [thread overview]
Message-ID: <20261015222908.760160-1-markus.mayer@broadcom.com> (raw)
Address potential document build issue when BR2_PER_PACKAGE_DIRECTORIES
is enabled.
The perf package wants to prevent the documentation from being built,
since it won't be installed anyway. The trick is to create an empty
GNUmakefile in the proper place. It did this by using a POST_PATCH hook.
The reason this approach works when BR2_PER_PACKAGE_DIRECTORIES is off
is that the build system ensures only one package builds at a time, so
Linux's "extract" stage and Linux Tool's "patch" stage can never execute
in parallel.
However, with per-package builds enabled, there is no guarantee that
Linux has finished extracting by the time the linux-tool's POST_PATCH
hook runs. This means the creation of GNUmakefile could silently be
skipped if that portion of the source code hadn't been extracted yet.
If, in addition to this, asciidoc happened to be installed on the build
host (/usr/bin/asciidoc), perf would detect this and enable the doc
build stage. At actual build time, it would use host-python3 (not the
host's system Python), which does NOT have asciidoc, and the build would
fail.
INSTALL libperf_headers
SYSHDR /local/users/jenkins/workspace/[...]/libperf/arch/[...]/unistd_64.h
INSTALL libbpf_headers
fatal: not a git repository: '.'
ASCIIDOC /local/users/jenkins/workspace/[...]/tools/perf/perf-amd-ibs.xml
fatal: not a git repository: '.'
[...]
ASCIIDOC /local/users/jenkins/workspace/[...]/tools/perf/perf-data.xml
/local/users/jenkins/workspace/buildroot/[...]/host/bin/python3:
No module named asciidoc
make[5]: *** [Makefile:275: [...]/perf-data.xml] Error 1
Turning the POST_PATCH hook into a PRE_CONFIGURE hook solves this timing
problem and guarantees that the "fake" GNUmakefile can be injected into
$(LINUX_DIR)/tools/perf/Documentation as intended.
Signed-off-by: Markus Mayer <markus.mayer@broadcom.com>
---
package/linux-tools/linux-tool-perf.mk.in | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
The primary reason for v2 is the updated email address. While I was at it, I
made the comment a little clearer. The actual code change is identical to
before.
https://lists.buildroot.org/pipermail/buildroot/2026-September/810498.html
diff --git a/package/linux-tools/linux-tool-perf.mk.in b/package/linux-tools/linux-tool-perf.mk.in
index 8c91c2cc6b0f..3271fd5683eb 100644
--- a/package/linux-tools/linux-tool-perf.mk.in
+++ b/package/linux-tools/linux-tool-perf.mk.in
@@ -141,12 +141,17 @@ endif
# distributions.
# We name it 'GNUmakefile' so that GNU make will use it instead of
# the existing 'Makefile'.
+#
+# This must be a PRE_CONFIGURE hook, not a POST_PATCH hook. Only the
+# configure step is ordered after "linux" (via LINUX_TOOLS_DEPENDENCIES).
+# For a POST_PATCH hook, tools/perf/Documentation/Makefile is not
+# guaranteed to exist yet.
define PERF_DISABLE_DOCUMENTATION
if [ -f $(LINUX_DIR)/tools/perf/Documentation/Makefile ]; then \
printf "%%:\n\t@:\n" >$(LINUX_DIR)/tools/perf/Documentation/GNUmakefile; \
fi
endef
-LINUX_TOOLS_POST_PATCH_HOOKS += PERF_DISABLE_DOCUMENTATION
+LINUX_TOOLS_PRE_CONFIGURE_HOOKS += PERF_DISABLE_DOCUMENTATION
# O must be redefined here to overwrite the one used by Buildroot for
# out of tree build. We build perf in $(LINUX_DIR)/tools/perf/ and not just
--
2.55.0
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot
next reply other threads:[~2026-10-15 22:29 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-15 22:29 Markus Mayer via buildroot [this message]
2026-10-15 22:32 ` [Buildroot] [PATCH v2] package/linux-tools/linux-tool-perf.mk.in: fix doc build issue Florian Fainelli via buildroot
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=20261015222908.760160-1-markus.mayer@broadcom.com \
--to=buildroot@buildroot.org \
--cc=markus.mayer@broadcom.com \
/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