package/linux-tools/linux-tool-perf.mk.in: fix doc build issue

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 <[email protected]>

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 <[email protected]>

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 <[email protected]>

Tested-by Florian Fainelli <[email protected]>

Reviewed-by Florian Fainelli <[email protected]>

---
 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

package/linux-tools/linux-tool-perf.mk.in +5 -0

index 8c91c2cc6b0f..3271fd5683eb 100644
@@ -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.