Presets and _deps folder question

I’m looking for a good link to any specific part of the documentation that talks about when the _deps folder might be wiped out. I’ve had a number of coworkers who like to use presets from within their IDE and in doing this they seem to be wiping out their _deps folder each time. I suspect there is a way to avoid this, but I don’t fully understand why _deps would be getting wiped out in the first place if you’re just repeatedly calling CMake with the same parameters. There are implications for the people doing this - i.e. fetch times are added to each call they make to CMake instead of just the first call.

EDIT: I should say that the _deps folder is getting repopulated - i.e. any FetchContent calls in the CMake project get executed as if the _deps folder did not already exist when it did in fact exist.

_deps is not a standard CMake thing, so where is this coming from in the first place?

1 Like

FetchContent creates that folder. It’s usually in the build directory, so it usually gets deleted only if you delete the entire build tree.

1 Like

Apologies - perhaps it’s not standard, but I noticed that FetchContent uses it for any fetched content that gets pulled in. Perhaps the name of the folder isn’t always the same - that’s just what I’ve seen on Windows.

I’ll get an example sequence that reproduces the issue. I realize this question is a bit incomplete without that.

Oh, if it’s FetchContent stuff…beyond my knowledge of the module. @craig.scott?

1 Like

FetchContent puts all its stuff under ${CMAKE_BINARY_DIR}/_deps by default. That location is controlled by the FETCHCONTENT_BASE_DIR variable (I would advise against changing it from its default).

You’d need to show what your FetchContent_Declare() calls are before I could comment further on why things might be getting repopulated on every CMake run.

2 Likes

Apologies. After some further investigation I couldn’t reproduce my coworkers’ problems with CMake alone. It is a function of their IDE or IDE settings (Visual Studio). My bad.

1 Like