Reconfigured the build when the requested compiler changes - #657
Merged
fdesbiens merged 1 commit intoAug 24, 2026
Merged
Conversation
CMake records the compiler it detected inside the build directory and keeps using it on every later configure. Since cmake/linux.cmake began honouring CC, that made a compiler switch silently ineffective: CC=gcc-14 ./run.sh build <cfg> against an existing build directory printed "ninja: no work to do", exited 0, and left the previous compiler in place. Anyone verifying a change against a second compiler would have been reading stale results while being told the build had succeeded. generate() now compares the compiler recorded in the build directory with the one currently requested, and reconfigures from scratch when they differ. The comparison uses the path as CMake records it, which is the unresolved path as given, so /usr/bin/gcc matches command -v gcc rather than the versioned target its symlink points at. build_libs() gets the same treatment. Only the C compiler is consulted: both trees that use this script declare LANGUAGES C, so no CXX compiler is ever detected. Nothing is reconfigured unless the compiler actually changed, so repeat builds stay incremental and the default path is unchanged. Assisted-by: Claude Code (Opus 5)
fdesbiens
added a commit
that referenced
this pull request
Aug 24, 2026
gcov reads a data format tied to the compiler that produced it. coverage.sh took whatever gcov was first on PATH, which was fine while the compiler was also whatever was first on PATH. #656 made cmake/linux.cmake honour CC and #657 made a compiler switch actually reconfigure the build, so that assumption no longer holds, and the first person to use the new capability would have hit this. Measured on dev with both of those merged: CC=gcc-14 ./run.sh build default_build_coverage # succeeds ./coverage.sh default_build_coverage # exit 64 gcov says why, if asked directly: tx_block_allocate.c.gcno:version 'B42*', prefer 'B33*' gcovr turns that into "GCOV returncode was 3" and exits 64 through a Python traceback, after the tests have already passed. It reads like a coverage bug rather than a toolchain mismatch, which is the part that would have cost someone an afternoon. gcov is now derived from CC rather than found on PATH, so the caller sets one variable instead of remembering two. GCOV still overrides, for a toolchain that does not follow the gcc/gcov naming, and a derived gcov that does not exist is reported as such instead of surfacing as a traceback. Verified, tx and smp, before and after: CC=gcc-14 was exit 64, now exit 0, 177 files and 1527/3827 lines CC unset exit 0, 177 files and 1527/3827 lines, unchanged CC=gcc-99 exit 1 naming gcov-99 and CC, rather than a traceback GCOV=gcov-14 with CC=gcc-99, exit 0, so the override still wins A mismatched pairing still fails, deliberately: reading a gcc-14 tree with the default gcc-13 gcov is exit 64 as before. Producing a number from mismatched data would be worse than refusing. Assisted-by: Claude Opus 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Follow-up to #656.
Problem
CMake records the compiler it detected inside the build directory and keeps using it on every later configure. Now that
cmake/linux.cmakehonoursCC, that turns a compiler switch into a silent no-op:It reports success, and the build is still gcc 13. Someone checking a change against a second compiler would be reading stale results while being told the build succeeded — the failure mode is a wrong answer rather than an error, which is what makes it worth fixing rather than documenting.
Change
generate()compares the compiler recorded in the build directory against the one currently requested, and reconfigures from scratch only when they differ.build_libs()gets the same treatment.The comparison uses the path in the form CMake records it — the unresolved path as given — so
/usr/bin/gccmatchescommand -v gccrather than the versioned target its symlink resolves to. Comparing resolved paths would have produced a spurious wipe on every single run.Only the C compiler is consulted: both trees that use this script (
test/tx/cmakeandtest/smp/cmake, which symlink to it) declareLANGUAGES C, so no CXX compiler is ever detected.Verification
Compiler selection,
test/tx/cmake:no work to do)CC=gcc-14CCno work to do)Suites, via the canonical
./run.sh build+./run.sh testpath:test/tx/cmake— 96/96 with gcc 13.3.0, and 96/96 withCC=gcc-14after the automatic reconfigure.test/smp/cmake— 110/110 with gcc 13.3.0, and 110/110 withCC=gcc-14.One note on the SMP tree:
threadx_smp_time_slice_testfails intermittently under a barectestinvocation but passes under the--repeat until-pass:2policy this script already applies, on both compilers and with and without this change. It is timing-sensitive and unrelated to this patch.