FetchContent can lead to inconsistent directory properties
Consider the case where we have:
FetchContent_Declare(
A
...
OVERRIDE_FIND_PACKAGE
)
FetchContent_Declare(
B
...
OVERRIDE_FIND_PACKAGE
)
FetchContent_MakeAvailable(A B)
and additionally, library A
depends on library B
, and the CMakeLists.txt
for library A
calls find_package(B)
.
Due to the way FetchContent
is implemented, this leads to library B
being added as a subdirectory of library A
, which means it inherits the directory properties from library A
, which is likely to be unexpected and undesirable.
There are several possible workarounds:
-
Inject (e.g. via a patch) code into library A and library B to try to reset important directory-level properties. Unfortunately for the
DEFINITIONS
property this is impossible due to #24010. -
If the dependency graph is known, we can specify the packages to
FetchContent_MakeAvailable
in topologically-sorted order. But in some cases the dependency graph is not readily available, since it may not otherwise be required.
I think the ideal solution would be to allow a PARENT
argument to add_subdirectory that specifies that some other directory (already known to CMake) will serve as the parent, rather than the current directory. Then FetchContent
could use this option to support more consistent property inheritance when using FetchContent
.