# Looking for help improving CMake configure time

**URL:** https://discourse.cmake.org/t/looking-for-help-improving-cmake-configure-time/9313
**Category:** Code
**Created:** [October 30, 2023, 5:31pm UTC](https://discourse.cmake.org/t/looking-for-help-improving-cmake-configure-time/9313 "2023-10-30T17:31:11Z")
**Posts on this page:** 4
**Page:** 1

<div class="post-metadata">

### Author: ![samuelpmish](https://discourse.cmake.org/user_avatar/discourse.cmake.org/samuelpmish/32/3308_2.png) [@samuelpmish](https://discourse.cmake.org/u/samuelpmish)
#### Post date: [October 30, 2023, 5:31pm UTC](https://discourse.cmake.org/t/looking-for-help-improving-cmake-configure-time/9313/1 "2023-10-30T17:31:11Z")

</div>

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

```auto
--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

---

<div class="post-metadata">

### Author: ![ben.boeckel](https://discourse.cmake.org/letter_avatar_proxy/v4/letter/b/ea5d25/32.png) [@ben.boeckel](https://discourse.cmake.org/u/ben.boeckel)
#### Post date: [October 30, 2023, 6:51pm UTC](https://discourse.cmake.org/t/looking-for-help-improving-cmake-configure-time/9313/2 "2023-10-30T18:51:57Z")

</div>

> [@samuelpmish](#):
>
> - 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.

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

> [@samuelpmish](#):
>
> 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.

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

---

<div class="post-metadata">

### Author: ![samuelpmish](https://discourse.cmake.org/user_avatar/discourse.cmake.org/samuelpmish/32/3308_2.png) [@samuelpmish](https://discourse.cmake.org/u/samuelpmish)
#### Post date: [October 30, 2023, 8:19pm UTC](https://discourse.cmake.org/t/looking-for-help-improving-cmake-configure-time/9313/3 "2023-10-30T20:19:19Z")

</div>

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`?

---

<div class="post-metadata">

### Author: ![ben.boeckel](https://discourse.cmake.org/letter_avatar_proxy/v4/letter/b/ea5d25/32.png) [@ben.boeckel](https://discourse.cmake.org/u/ben.boeckel)
#### Post date: [October 31, 2023, 12:24am UTC](https://discourse.cmake.org/t/looking-for-help-improving-cmake-configure-time/9313/4 "2023-10-31T00:24:02Z")

</div>

> [@samuelpmish](#):
>
> Is there something preventing findMPI from caching its compiler queries, I wonder?

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

> [@samuelpmish](#):
>
> Is it expected to do something else that improves configure times, or is it just a more portable alternative to `rm build/CMakeCache.txt`?

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/`.