Looking for help improving CMake configure time

Code
1

Hi,

I’m looking for help on how to reduce cmake configure time for a C++ project. This project takes about 10s to configure, and when profiling with

--profiling-format=google-trace
--profiling-output=cmake-configuration-stage-profiling-data.json

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.

Thank you,

Sam

2

try_compile results should, generally, be cached. Are these calls not cached for some reason?

There is the --fresh option in CMake 3.24 and newer.

3

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?

4

Possibly. Could you provide a list of the try_compile requests that aren’t properly cached in your case?

No, it’s not expected to make things faster, but it is easier than integrating an rm into the “restart this build please” workflow. I believe it also removes some bits from CMakeFiles/.