madspace install.py: add --clean for a rebuild from scratch

[oliviermattelaer]

Follow-up to #176 (based on its branch, so the diff stays reviewable; GitHub retargets this to main when #176 merges).

Why

A rebuild reuses the CMake tree in madspace/build, which is what keeps it incremental — seconds, instead of recompiling madspace and its vendored OpenBLAS. When that tree is in the way (a toolchain change, a half-finished build), the only cure was a hand-written rm -rf madspace/build madspace/install that users had to know.

--clean

Deletes madspace/build and madspace/install, then installs as usual:

python madspace/install.py --source --clean

install madspace --clean at the MG7 prompt works too, since the arguments are passed straight through.

It is deliberately opt-in. Cleaning on every install madspace would turn the routine rebuild after a git pull — the one the source-hash warning in launch.py asks for — into a full one, which is the slow path for the most common case.

The settings had to move

install_settings.json lived inside madspace/build, so a naive wipe erased it and the next --yes rebuild silently fell back to the platform defaults — the failure mode #176 just fixed, through a different door. So:

• the file moves to madspace/install_settings.json, outside both cleaned directories (and gitignored);
• the old location is still read, so an existing installation keeps its choices;
• main() reads the settings before wiping.

--clean --yes therefore still rebuilds the remembered configuration, from scratch.

Narrow auto-clean

The installer also wipes the build tree by itself when CMakeCache.txt shows that reusing it cannot work: a compiler named by CC/CXX, or an interpreter, that is no longer the current one. CMake answers both with "you have changed variables that require your cache to be deleted".

The check is deliberately narrow — anything CMake can pick up by reconfiguring is not reported, so ordinary rebuilds stay incremental. The compilers are only compared when CC/CXX name them explicitly; without those, CMake runs its own search and the cached path is not something to second-guess. This auto-clean removes only build/, never the install.

Checked against a real build tree on macOS (clang, direnv venv): no staleness reported; a changed CXX is caught.

Tests

16 more in tests/unit_tests/various/test_madspace_install.py, 33 in total, nothing built. They cover clean_install_dirs, the settings round-trip across a clean, the legacy-location fallback, CMakeCache.txt parsing and stale_build_reason, plus main() with --clean and with a stale cache.

Three mutations of the source, each caught:

• cleaning before the settings are read → the "keeps the settings" test fails;
• the settings file back inside build/ → the location-invariant test fails;
• auto-clean wiping the install too → the "build tree only" test fails.

./tests/test_manager.py test_madspace_install -t0 → Ran 33 tests, OK.

Not included: an --uninstall (wipe and stop) — a separate thing, happy to add it if wanted.

🤖 Generated with Claude Code