it seems that most of the time is spent in try_compile expressions. In particular:
about ~4s of that time is spent in find_package(MPI), ~90% of which is in try_compile expressions to probe what versions of Fortran are supported by a compiler.
another ~1s of time is spent in find_package(BLAS), also in try_compile invocations checking if fortran functions exist.
another ~2s are used in try_compile expressions in other contexts.
Is there any way to avoid repaying these costs on each reconfigure? It seems like the flags / language versions supported by a compiler could be detected once (per-compiler, rather than per-compiler-per-project) and saved, rather than being rediscovered each time.
On a related note: when should a CMake user delete the CMakeCache.txt before reconfiguring? It seems like some build system changes are not applied on a reconfigure without first deleting the CMakeCache.txt. However, I don’t fully understand the rules, so more often than not I find myself deleting the CMakeCache.txt and reconfiguring from scratch to ensure changes propagate.
When I reconfigure this project without deleting the CMakeCache.txt, it does take less time (about 5 seconds, rather than 10). Almost all of the remaining time for reconfigure is spent in find_package(MPI ...) which is try_compile-dominated as mentioned above.
Is there something preventing findMPI from caching its compiler queries, I wonder?
There is the --fresh option in CMake 3.24 and newer.
Thanks, I’ve never heard of that option before, but the documentation makes it sound like just a shortcut for deleting the CMakeCache.txt file. Is it expected to do something else that improves configure times, or is it just a more portable alternative to rm build/CMakeCache.txt?