Delete Cache and Reconfigure with FetchContent

[stertingen]

Brief Issue Summary

I'm having a CMake project with dependencies which are pulled using FetchContent.
CMake creates build directories and cache files at build/_deps which are not cleared when running "Delete Cache and Reconfigure".
This usually breaks when the generator is changed (Make vs Ninja).

Steps to Reproduce:

1. Start of with a clean project
2. Add some external library with CMake support using FetchContent, for example:

FetchContent_Declare(cmrc
    URL "https://github.com/vector-of-bool/cmrc/archive/refs/tags/2.0.1.tar.gz"
    DOWNLOAD_EXTRACT_TIMESTAMP OFF
)
FetchContent_GetProperties(cmrc)
if (NOT cmrc_POPULATED)
    FetchContent_Populate(cmrc)
    add_subdirectory(${cmrc_SOURCE_DIR} ${cmrc_BINARY_DIR} EXCLUDE_FROM_ALL)
endif()

3. Declare at least two kits with different preferred generators (in my case auto-discovered MinGW with Make and Visual Studio with Ninja):

[
  {
    "name": "GCC 12.2.0 x86_64-w64-mingw32 (mingw64)",
    "compilers": {
      "C": "C:\\msys64\\mingw64\\bin\\gcc.exe",
      "CXX": "C:\\msys64\\mingw64\\bin\\g++.exe"
    },
    "isTrusted": true,
    "environmentVariables": {
      "CMT_MINGW_PATH": "C:\\msys64\\mingw64\\bin"
    },
    "preferredGenerator": {
      "name": "MinGW Makefiles"
    }
  },
  {
    "name": "Clang 15.0.1 (GNU CLI) for MSVC 17.5.33530.505 (Visual Studio Professional 2022 Release - amd64)",
    "visualStudio": "da53be4e",
    "visualStudioArchitecture": "x64",
    "compilers": {
      "C": "C:\\Program Files\\Microsoft Visual Studio\\2022\\Professional\\VC\\Tools\\Llvm\\x64\\bin\\clang.exe",
      "CXX": "C:\\Program Files\\Microsoft Visual Studio\\2022\\Professional\\VC\\Tools\\Llvm\\x64\\bin\\clang.exe"
    },
    "isTrusted": true
  }
]

4. Select one kit and configure project (no need to build), check that the library gets downloaded and configured at build/_deps
5. Select the other kit and configure project

As a workaround, I manually delete the _deps directory when reconfiguring.

CMake Tools Diagnostics

No response

Debug Log

No response

Additional Information

No response

[benmcmorran]

Thanks for the report! I'm guessing this is happening because "Delete Cache and Reconfigure" literally deletes the CMakeCache.txt file and then runs the configure step again. I'm marking this issue as a request to instead delete the entire binary output directory before regenerating.

[msaeedsaeedi]

This is very critical issue when dealing with multiple massive libraries. It must be resolved as soon as possible

[gcampbell-msft]

#3783 This PR should have given a setting that resolves this, could you try the cmake.deleteBuildDirOnCleanConfigure setting in the pre-release channel?

[xavgru12]

I am having the same problem. cmake --fresh essentially does it for the cmake project, however it ignores fetchcontent. Is there any cmake command which does this functionality for fetchcontent?

[xavgru12]

@stertingen Deleting CMakeCache.txt inside _deps is enough.

[gcampbell-msft]

@xavgru12 Did you try the cmake.deleteBuildDirOnCleanConfigure setting?

[xavgru12]

@gcampbell-msft
I have not tried that, but this suggests deleting the entire build dir. This seems to be overkill. I would need to have CMakeFiles and CMakeCache.txt deleted inside the fetchcontent dir.

[gcampbell-msft]

@xavgru12 How does it work for you though? Either way everything is going to get regenerated (for the most part), so deleting the entire build dir ensures that things happen as you desire and correctly.

[xavgru12]

@gcampbell-msft
One use case is when I rename the root folder. This breaks something using -G Visual Studio (Windows). Using cmake --fresh (reconfigure) this would be fixed. However fetchcontent content within _deps is still broken. Deleting CMakeCache.txt inside _deps and starting cmake again fixes it.

[gcampbell-msft]

@xavgru12 It sounds like what you're suggesting might be that we could improve our "delete cache and reconfigure" step to, if you're using a cmake.exe version past 3.24, we could actually utilize the --fresh argument, and it would solve this issue. Am I understand that correctly?

It looks like in 3.30 there was a policy added that fixes the fetchcontent issue.

It sounds like there is some work we could do here, but in the meantime, the cmake.deleteBuildDirOnCleanConfigure would work around this issue.

[xavgru12]

@gcampbell-msft
What I am saying is that cmake --fresh is doing the same as delete cache and reconfigure. However this still does not resolve the issue with fetchcontent using 3.31. The workaround to delete the entire build dir is fine but just a workaround and overkill. It is not a good solution.

[gcampbell-msft]

@xavgru12 Do you notice performance differences when deleting the entire build directory? It's regenerating everything either way, correct? In which case, the solution has the same impact?

[gcampbell-msft]

Since this fixes the issue and I did some small testing and didn't find any performance difference, this is determined to be a good solution, though it could be more refined.

Since it solves this bug, I'm going to close it. However, we're happy to consider an improvement request to make it more refined rather than deleting the entire build dir. Please create an issue for this, and we'd also be happy to take an OSS contribution!

Thanks for all your help and contributions.

[xavgru12]

@gcampbell-msft
Deleting the build directory has a huge impact if the build directory contains obj/binary files which is the case for many people. Can we make sure to push through the root cause to Kitware? It is always cleaner to fix root causes instead of building workarounds.

[gcampbell-msft]

@xavgru12 I would agree, however, in a quick test, after a reconfigure, building through cmake still causes a rebuild of the obj/binary files.

And yes, I would encourage you to create a bug here: https://gitlab.kitware.com/cmake/cmake/-/issues

[xavgru12]

@gcampbell-msft
I have done tests with cmake --fresh and cmake does not require to build again. This is a difference to reconfigure. It would be good to investigate in the differences. Maybe cmake --fresh is a more sophisticated way of reconfiguring.