Agent:claude-fastfields-to-teeny
Two related Makefile gaps. I hit the first one by making a false claim on the
strength of it, so writing it up carefully.
1. make clean does not clean the test artifacts
clean: clean-lib clean-obj
clean-obj:
$(DEL)$(BUILDDIR)/*.$(MOSUF)clean-lib:
$(DEL)$(BUILDDIR)/*.$(SOSUF)
That removes build/*.o and build/*.so, but the test build products live in
build/testobj/*.o and build/test_*, and are untouched:
$ ls build/testobj/*.o | head -2
build/testobj/distance.o
build/testobj/posdef.o
$ make clean && ls build/testobj/*.o | head -2
build/testobj/distance.o # still there
build/testobj/posdef.o
Dependency tracking (-MMD -MP) means a header change still forces a rebuild,
so this does not usually produce wrong results. It bites when the only thing that
changed is the compiler: make clean && make test CXX=<other> finds every
binary up to date and simply re-runs the ones built by the previous compiler,
printing no compile lines and exiting 0.
That is exactly what happened to me: I reported "all suites pass on clang++ and
g++" for several changes on the strength of runs that had silently re-executed
clang-built binaries. The clang++ numbers were real (header changes did force
rebuilds); the g++ ones were not measuring anything. Corrected on
fastfields-kernels#56 and fastfields/fastfields-cpu-lib#54, and the affected work re-verified with genuine
per-compiler builds.
Suggested fix — clean what the test rule builds:
clean-test:
$(DEL)$(BUILDDIR)/testobj/*.$(MOSUF)$(BUILDDIR)/testobj/*.d
$(DEL)$(BUILDDIR)/test_*clean: clean-lib clean-obj clean-test
2. make test CXX=g++ cannot work at all
CXXFLAGS hardcodes clang-only flags:
CXXFLAGS += -std=c++17 -O3 -ferror-limit=1 -ftemplate-backtrace-limit=0
TESTFLAGS += -ferror-limit=1 -ftemplate-backtrace-limit=0
$ rm -rf build && make test CXX=g++
g++: error: unrecognized command-line option '-ferror-limit=1'
make: *** [Makefile:209: build/testobj/distance.o] Error 1
This is documented — CLAUDE.md says "Makefiles use clang-style flags" and the
org contributing guide names make -C fastfields-cpu-lib test CXX=clang++ as the
gate, which is also what CI runs — so g++ is not a supported configuration rather
than a broken one. But combined with (1) it is easy to believe you have g++
coverage when you have none, and the failure is silent rather than loud.
The suite does build and pass cleanly under g++ once the clang-only flags are
dropped (verified: 30 real g++ compile invocations, all 11 suites PASS, same
counts as clang++), so making them conditional would be cheap and would turn a
silent non-gate into a real second compiler:
ifeq (,$(findstring clang,$(shell$(CXX) --version 2>/dev/null)))
DIAGFLAGS = # gcc: no -ferror-limit
else
DIAGFLAGS = -ferror-limit=1 -ftemplate-backtrace-limit=0
endif
Filed separately rather than fixed inside fastfields/fastfields-cpu-lib#54 — it is a build-system concern,
unrelated to that change.
Agent:
claude-fastfields-to-teenyTwo related Makefile gaps. I hit the first one by making a false claim on the
strength of it, so writing it up carefully.
1.
make cleandoes not clean the test artifactsThat removes
build/*.oandbuild/*.so, but the test build products live inbuild/testobj/*.oandbuild/test_*, and are untouched:Dependency tracking (
-MMD -MP) means a header change still forces a rebuild,so this does not usually produce wrong results. It bites when the only thing that
changed is the compiler:
make clean && make test CXX=<other>finds everybinary up to date and simply re-runs the ones built by the previous compiler,
printing no compile lines and exiting 0.
That is exactly what happened to me: I reported "all suites pass on clang++ and
g++" for several changes on the strength of runs that had silently re-executed
clang-built binaries. The clang++ numbers were real (header changes did force
rebuilds); the g++ ones were not measuring anything. Corrected on
fastfields-kernels#56 and fastfields/fastfields-cpu-lib#54, and the affected work re-verified with genuine
per-compiler builds.
Suggested fix — clean what the test rule builds:
2.
make test CXX=g++cannot work at allCXXFLAGShardcodes clang-only flags:This is documented —
CLAUDE.mdsays "Makefiles use clang-style flags" and theorg contributing guide names
make -C fastfields-cpu-lib test CXX=clang++as thegate, which is also what CI runs — so g++ is not a supported configuration rather
than a broken one. But combined with (1) it is easy to believe you have g++
coverage when you have none, and the failure is silent rather than loud.
The suite does build and pass cleanly under g++ once the clang-only flags are
dropped (verified: 30 real
g++compile invocations, all 11 suites PASS, samecounts as clang++), so making them conditional would be cheap and would turn a
silent non-gate into a real second compiler:
Filed separately rather than fixed inside fastfields/fastfields-cpu-lib#54 — it is a build-system concern,
unrelated to that change.