Bump googletest to v1.18.0

[d-torrance]

Googletest 1.18.0 was just released.

Draft for now to test the builds.

No AI used I asked Claude to diagnose why the macOS cmake build was failing, and it added a couple commits. See below.

[d-torrance]

This comment was written by Claude (Claude Code), at @d-torrance's request, after investigating the cmake-macos-15-brew-clang failure on this branch.

Two CMake-only commits have been added. Neither is a googletest change — the first one fixes a pre-existing bug that the temporary *REMOVE ME* commit exposed, and the second is an unrelated bug found while investigating it. googletest 1.18.0 itself is fine: the autotools-ubuntu-24.04 job built it from the submodule and ran the engine unit tests against it, [ PASSED ] 257 tests.

Why cmake-macos-15-brew-clang failed

It was a link failure, not a test failure:

Undefined symbols for architecture arm64:
  "testing::InitGoogleTest(int*, char**)", referenced from: _main in testMain.cpp.o

M2-unit-tests was linked with no gtest library at all. Macaulay2/e/CMakeLists.txt guards the link with if(GTEST_FOUND), and check-libraries.cmake deliberately unsets GTEST_FOUND when a library is found on the system but listed in BUILD_LIBRARIES, so that build-libraries builds our own copy. Normally the reconfigure that the build-libraries target performs then finds the copy we installed under M2_HOST_PREFIX and the guard passes.

That reconfigure never converged for GTest. memtailor, mathic and mathicgb each run their own find_package(GTest) under if(NOT GTEST_FOUND) — which fires precisely when check-libraries has unset GTEST_FOUND to request a self-build — and that re-caches GTest_DIR pointing at the Homebrew copy after the loop in check-libraries has cleared it. The next configure reads that stale value, classifies it as "on the system, but we want to build it", and unsets GTEST_FOUND again. Permanently one configure behind, so the link was skipped every time.

You can see it in the job logs: the failing configure prints -- Found GTest: twice (Homebrew, then usr-host), where a passing build on development prints it once.

24828375bd clears the stale <Package>_DIR before searching, for every library we intend to build. Verified against the real tree: M2-unit-tests goes from having no gtest on its link line to usr-host/lib/libgtest.a + libgtest_main.a on the reconfigure, and the default (system gtest) path is unchanged.

Three notes for anyone who hits something similar:

• Only a system googletest of 1.16 or newer triggers this, which is why macOS (Homebrew 1.18.0) broke and Ubuntu (libgtest-dev 1.14.0) did not — there the stale GTest_DIR fails the version check in find_package(GTest 1.16) and CMake carries on searching, finding our own copy by itself.
• autotools was never affected: Macaulay2/e/unit-tests/Makefile.in puts -lgtest in LOADLIBES unconditionally, with no found-flag gating.
• cmake-ubuntu-24.04 passed because M2-unit-tests is EXCLUDE_FROM_ALL and the CTest step is macOS-only, so it never linked the target.

The gftables commit

Separate bug, found while checking whether other libraries could hit the same trap (they can't — GTest is the only entry of LIBRARY_OPTIONS that anything else calls find_package on). The copy of factory's gftables into the distribution tree was guarded only on the destination not already existing, so it happened once, on the first configure — when GFTABLESDIR still points at the factory already on the system. With BUILD_LIBRARIES=factory, GFTABLESDIR correctly moves to M2_HOST_PREFIX on the reconfigure, but the destination exists by then, so we distributed the system's tables alongside the factory we had just built.

d3178ebd18 copies again when GFTABLESDIR differs from wherever we last copied from. It also removes the previous copy first: file(COPY) optimizes out files whose timestamps match and compares them at a coarser resolution than it writes them, so it would not reliably replace the tables in place — the first version of the fix re-ran the copy and still shipped the old tables.

Verified with two factory installs carrying distinguishable tables: before, the reconfigure shipped the system's; after, it ships the one we built. A normal build (system factory, no BUILD_LIBRARIES) still copies exactly once and does not re-copy on subsequent configures.

This one is independent of the googletest bump and could reasonably be split into its own PR.

Not addressed

Nothing in CI currently exercises BUILD_LIBRARIES at all, which is why a bug this structural survived — the *REMOVE ME* commit is the first thing to have tried it. Worth considering whether some job should keep doing so.

[d-torrance]

Builds passed!

https://github.com/Macaulay2/M2/actions/runs/31493285619