kbuild: log compiler version in tuxmake builds#3116
Conversation
bhcopeland
force-pushed
the
kbuild-log-clang-version
branch
from
3f31b8e to
bcccd5d
Compare
|
tuxmake already collects this, it writes compiler.version_full into its metadata.json. |
It does, but I moved to this approach because it won't work for failed builds. We should make a similar change to metadata.json (for structured data). |
I think we should save and use what we want from tuxmake's metadata.json before we overwrite that with the "new" metadata.json file. |
bhcopeland
force-pushed
the
kbuild-log-clang-version
branch
from
3fbd096 to
b07aba2
Compare
|
LGTM, the only thing maybe add tests that goes along with the changes? |
When investigating a build failure it helps to know the exact compiler version that produced it, but the build log never shows one. The job parameters only carry the requested toolchain name (e.g. clang-21), and with the null runtime tuxmake builds with whatever compiler the build environment has installed, so the requested name alone does not describe what actually ran. Print the compiler's --version into build.log just before the tuxmake invocation, so the version is visible even when the build fails. The binary is resolved the same way tuxmake resolves it (toolchain compiler plus tuxmake's arch-default CROSS_COMPILE) rather than from the job's cross_compile parameter, because the two can differ; arc jobs set arc-elf32- while tuxmake builds with arc-linux-gnu-. Fall back to plain clang when tuxmake is not importable. Add tests covering the probe placement before the tuxmake invocation, the tuxmake-based binary resolution and the fallback behaviour. Signed-off-by: Ben Copeland <ben.copeland@linaro.org>
| if version_full: | ||
| metadata["build"]["compiler_version"] = version_full | ||
| self._compiler_version = version_full | ||
|
|
There was a problem hiding this comment.
Maybe create a function def _preserve_tuxmake_metadata() and call that just above the call to self._write_metadata() .
When finalising a build, kbuild replaces tuxmake's metadata.json with its own, discarding everything tuxmake records about the build environment (compiler, tools, os, uname and so on). Rename tuxmake's file to tuxmake_metadata.json before writing ours, following the existing kselftest_metadata.json convention, and carry compiler.version_full over as build.compiler_version in metadata.json and compiler_version in the node data, so the exact compiler version can reach the API and the dashboard. Add tests covering the rename, the compiler version carry-over and the handling of missing, foreign and invalid metadata files. Signed-off-by: Ben Copeland <ben.copeland@linaro.org>
bhcopeland
force-pushed
the
kbuild-log-clang-version
branch
from
b07aba2 to
02ed6c9
Compare
|
All addressed, thank you very much for your feedback @roxell! |
3 participants
When investigating a build failure it helps to know the exact
compiler version that produced it, but the build log never shows
one. The job parameters only carry the requested toolchain name
(e.g. clang-21), and with the null runtime tuxmake builds with
whatever compiler the build environment has installed, so the
requested name alone does not describe what actually ran.
Print the compiler's --version into build.log just before the
tuxmake invocation, so the version is visible even when the build
fails. The binary is resolved the same way tuxmake resolves it
(toolchain compiler plus tuxmake's arch-default CROSS_COMPILE)
rather than from the job's cross_compile parameter, because the two
can differ; arc jobs set arc-elf32- while tuxmake builds with
arc-linux-gnu-. Fall back to plain clang when tuxmake is not
importable.