FetchContent: Deprecate FetchContent_Populate(depName)

Projects should use FetchContent_MakeAvailable(depName)
instead. Policy CMP0169 provides backward compatibility.
This commit is contained in:
Craig Scott
2024-05-25 18:59:01 +10:00
parent bc70b458ad
commit 4370fcf750
33 changed files with 293 additions and 137 deletions

View File

@@ -57,6 +57,7 @@ Policies Introduced by CMake 3.30
.. toctree::
:maxdepth: 1
CMP0169: FetchContent_Populate(depName) single-argument signature is deprecated. </policy/CMP0169>
CMP0168: FetchContent implements steps directly instead of through a sub-build. </policy/CMP0168>
CMP0167: The FindBoost module is removed. </policy/CMP0167>
CMP0166: TARGET_PROPERTY evaluates link properties transitively over private dependencies of static libraries. </policy/CMP0166>

49
Help/policy/CMP0169.rst Normal file
View File

@@ -0,0 +1,49 @@
CMP0169
-------
.. versionadded:: 3.30
Calling :command:`FetchContent_Populate` with a single argument (the name of
a declared dependency) is deprecated.
Prior to the introduction of :command:`FetchContent_MakeAvailable`, projects
populated previously declared content (with :command:`FetchContent_Declare`)
using the following pattern:
.. code-block:: cmake
FetchContent_GetProperties(depname)
if(NOT depname_POPULATED)
FetchContent_Populate(depname)
add_subdirectory(${depname_SOURCE_DIR} ${depname_BINARY_DIR})
endif()
The above pattern does not support a number of features that have been added
to :module:`FetchContent` over time. It ignores options like ``SYSTEM`` and
``EXCLUDE_FROM_ALL`` which may be given to :command:`FetchContent_Declare`,
but can't be made known to the above project code. It also does not support
:ref:`dependency providers <dependency_providers_overview>`.
Projects should call :command:`FetchContent_MakeAvailable` instead of using
the above pattern.
CMake 3.30 and above prefers to reject calls to
:command:`FetchContent_Populate` with the name of a declared dependency.
This policy provides compatibility for projects that have not been updated
to call :command:`FetchContent_MakeAvailable` instead.
The ``OLD`` behavior of this policy allows :command:`FetchContent_Populate`
to be called with the name of a declared dependency.
The ``NEW`` behavior halts with a fatal error in such cases.
.. note::
Calling :command:`FetchContent_Populate` with the full population details
as command arguments rather than just a dependency name remains fully
supported. Only the form calling :command:`FetchContent_Populate` with a
single argument (the name of a previously declared dependency) is deprecated
with this policy.
.. |INTRODUCED_IN_CMAKE_VERSION| replace:: 3.30
.. |WARNS_OR_DOES_NOT_WARN| replace:: warns
.. include:: STANDARD_ADVICE.txt
.. include:: DEPRECATED.txt

View File

@@ -0,0 +1,8 @@
deprecate-fetchcontent_populate
-------------------------------
* Calling :command:`FetchContent_Populate` with just the name of a
dependency is now deprecated. Projects should call
:command:`FetchContent_MakeAvailable` instead. See policy :policy:`CMP0169`.
Calling :command:`FetchContent_Populate` with full population details
rather than just a dependency name remains fully supported.

View File

@@ -68,33 +68,6 @@ first instead of repeating the population again.
See the :ref:`Examples <fetch-content-examples>` which demonstrate
this scenario.
In some cases, the main project may need to have more precise control over
the population, or it may be required to explicitly define the population
steps in a way that cannot be captured by the declared details alone.
For such situations, the lower level :command:`FetchContent_GetProperties` and
:command:`FetchContent_Populate` commands can be used. These lack the richer
features provided by :command:`FetchContent_MakeAvailable` though, so their
direct use should be considered a last resort. The typical pattern of such
custom steps looks like this:
.. code-block:: cmake
# NOTE: Where possible, prefer to use FetchContent_MakeAvailable()
# instead of custom logic like this
# Check if population has already been performed
FetchContent_GetProperties(depname)
if(NOT depname_POPULATED)
# Fetch the content using previously declared details
FetchContent_Populate(depname)
# Set custom variables, policies, etc.
# ...
# Bring the populated content into the build
add_subdirectory(${depname_SOURCE_DIR} ${depname_BINARY_DIR})
endif()
The ``FetchContent`` module also supports defining and populating
content in a single call, with no check for whether the content has been
populated elsewhere already. This should not be done in projects, but may
@@ -316,8 +289,8 @@ Commands
:command:`FetchContent_GetProperties`, then skip the remaining steps
below and move on to the next dependency in the list.
* Call :command:`FetchContent_Populate` to populate the dependency using
the details recorded by an earlier call to :command:`FetchContent_Declare`.
* Populate the dependency using the details recorded by an earlier call
to :command:`FetchContent_Declare`.
Halt with a fatal error if no such details have been recorded.
:variable:`FETCHCONTENT_SOURCE_DIR_<uppercaseName>` can be used to override
the declared details and use content provided at the specified location
@@ -331,10 +304,10 @@ Commands
``<name>Config.cmake`` and ``<name>ConfigVersion.cmake``).
The directory that the :variable:`CMAKE_FIND_PACKAGE_REDIRECTS_DIR`
variable points to is cleared at the start of every CMake run.
If no config file exists when :command:`FetchContent_Populate` returns,
a minimal one will be written which :command:`includes <include>` any
``<lowercaseName>-extra.cmake`` or ``<name>Extra.cmake`` file with the
``OPTIONAL`` flag (so the files can be missing and won't generate a
If no config file exists after populating the dependency in the previous
step, a minimal one will be written which :command:`includes <include>`
any ``<lowercaseName>-extra.cmake`` or ``<name>Extra.cmake`` file with
the ``OPTIONAL`` flag (so the files can be missing and won't generate a
warning). Similarly, if no config version file exists, a very simple
one will be written which sets ``PACKAGE_VERSION_COMPATIBLE`` and
``PACKAGE_VERSION_EXACT`` to true. This ensures all future calls to
@@ -428,68 +401,13 @@ Commands
.. command:: FetchContent_Populate
.. note::
Where possible, prefer to use :command:`FetchContent_MakeAvailable`
instead of implementing population manually with this command.
.. code-block:: cmake
FetchContent_Populate(<name>)
In most cases, the only argument given to ``FetchContent_Populate()`` is the
``<name>``. When used this way, the command assumes the content details have
been recorded by an earlier call to :command:`FetchContent_Declare`. The
details are stored in a global property, so they are unaffected by things
like variable or directory scope. Therefore, it doesn't matter where in the
project the details were previously declared, as long as they have been
declared before the call to ``FetchContent_Populate()``. Those saved details
are then used to populate the content using a method based on
:command:`ExternalProject_Add` (see policy :policy:`CMP0168` for important
behavioral aspects of how that is done). The implementation ensures that if
the content has already been populated in a previous CMake run, that content
will be reused rather than repopulating them again. For the common case
where population involves downloading content, the cost of the download is
only paid once.
An internal global property records when a particular content population
request has been processed. If ``FetchContent_Populate()`` is called more
than once for the same content name within a configure run, the second call
will halt with an error. Projects can and should check whether content
population has already been processed with the
:command:`FetchContent_GetProperties` command before calling
``FetchContent_Populate()``.
``FetchContent_Populate()`` will set three variables in the scope of the
caller:
``<lowercaseName>_POPULATED``
This will always be set to ``TRUE`` by the call.
``<lowercaseName>_SOURCE_DIR``
The location where the populated content can be found upon return.
``<lowercaseName>_BINARY_DIR``
A directory intended for use as a corresponding build directory.
The main use case for the ``<lowercaseName>_SOURCE_DIR`` and
``<lowercaseName>_BINARY_DIR`` variables is to call
:command:`add_subdirectory` immediately after population:
.. code-block:: cmake
FetchContent_Populate(FooBar)
add_subdirectory(${foobar_SOURCE_DIR} ${foobar_BINARY_DIR})
The values of the three variables can also be retrieved from anywhere in the
project hierarchy using the :command:`FetchContent_GetProperties` command.
The ``FetchContent_Populate()`` command also supports a syntax allowing the
content details to be specified directly rather than using any saved
details. This is more low-level and use of this form is generally to be
avoided in favor of using saved content details as outlined above.
Nevertheless, in certain situations it can be useful to invoke the content
population as an isolated operation (typically as part of implementing some
other higher level feature or when using CMake in script mode):
The ``FetchContent_Populate()`` command is a self-contained call which can
be used to perform content population as an isolated operation.
It is rarely the right command to use, projects should almost always use
:command:`FetchContent_Declare` and :command:`FetchContent_MakeAvailable`
instead. The main use case for ``FetchContent_Populate()`` is in
:ref:`CMake script mode <Script Processing Mode>` as part of implementing
some other higher level custom feature.
.. code-block:: cmake
@@ -502,39 +420,29 @@ Commands
...
)
This form has a number of key differences to that where only ``<name>`` is
provided:
- All required population details are assumed to have been provided directly
in the call to ``FetchContent_Populate()``. Any saved details for
``<name>`` are ignored.
- No check is made for whether content for ``<name>`` has already been
populated.
- No global property is set to record that the population has occurred.
- No global properties record the source or binary directories used for the
populated content.
- The ``FETCHCONTENT_FULLY_DISCONNECTED`` and
``FETCHCONTENT_UPDATES_DISCONNECTED`` cache variables are ignored.
The ``<lowercaseName>_SOURCE_DIR`` and ``<lowercaseName>_BINARY_DIR``
variables are still returned to the caller, but since these locations are
not stored as global properties when this form is used, they are only
available to the calling scope and below rather than the entire project
hierarchy. No ``<lowercaseName>_POPULATED`` variable is set in the caller's
scope with this form.
At least one option must be specified after `<name>`, otherwise the call
is interpreted differently (see :ref:`below <FetchContent_Populate-depName>`).
The supported options for ``FetchContent_Populate()`` are the same as those
for :command:`FetchContent_Declare()`. Those few options shown just
above are either specific to ``FetchContent_Populate()`` or their behavior is
slightly modified from how :command:`ExternalProject_Add` treats them:
for :command:`FetchContent_Declare()`, with a few exceptions. The following
do not relate to populating content with ``FetchContent_Populate()`` and
therefore are not supported:
* ``EXCLUDE_FROM_ALL``
* ``SYSTEM``
* ``OVERRIDE_FIND_PACKAGE``
* ``FIND_PACKAGE_ARGS``
The few options shown in the signature above are either specific to
``FetchContent_Populate()``, or their behavior is slightly modified from how
:command:`ExternalProject_Add` treats them:
``QUIET``
The ``QUIET`` option can be given to hide the output associated with
populating the specified content. If the population fails, the output will
be shown regardless of whether this option was given or not so that the
cause of the failure can be diagnosed. The :variable:`FETCHCONTENT_QUIET`
cache variable has no effect on ``FetchContent_Populate()`` calls where the
content details are provided directly.
variable has no effect on ``FetchContent_Populate()`` calls of this form
where the content details are provided directly.
.. versionchanged:: 3.30
The ``QUIET`` option and :variable:`FETCHCONTENT_QUIET` variable have no
@@ -575,6 +483,19 @@ Commands
- ``INSTALL_COMMAND``
- ``TEST_COMMAND``
With this form, the :variable:`FETCHCONTENT_FULLY_DISCONNECTED` and
:variable:`FETCHCONTENT_UPDATES_DISCONNECTED` variables are ignored.
When this form of ``FetchContent_Populate()`` returns, the following
variables will be set in the scope of the caller:
``<lowercaseName>_SOURCE_DIR``
The location where the populated content can be found upon return.
``<lowercaseName>_BINARY_DIR``
A directory originally intended for use as a corresponding build directory,
but is unlikely to be relevant when using this form of the command.
If using ``FetchContent_Populate()`` within
:ref:`CMake script mode <Script Processing Mode>`, be aware that the
implementation sets up a sub-build which therefore requires a CMake
@@ -592,6 +513,54 @@ Commands
.. versionadded:: 3.18
Added support for the ``DOWNLOAD_NO_EXTRACT`` option.
.. _`FetchContent_Populate-depName`:
The command supports another form, although it should no longer be used:
.. code-block:: cmake
FetchContent_Populate(<name>)
.. versionchanged:: 3.30
This form is deprecated. Policy :policy:`CMP0169` provides backward
compatibility for projects that still need to use this form, but projects
should be updated to use :command:`FetchContent_MakeAvailable` instead.
In this form, the only argument given to ``FetchContent_Populate()`` is the
``<name>``. When used this way, the command assumes the content details have
been recorded by an earlier call to :command:`FetchContent_Declare`. The
details are stored in a global property, so they are unaffected by things
like variable or directory scope. Therefore, it doesn't matter where in the
project the details were previously declared, as long as they have been
declared before the call to ``FetchContent_Populate()``. Those saved details
are then used to populate the content using a method based on
:command:`ExternalProject_Add` (see policy :policy:`CMP0168` for important
behavioral aspects of how that is done).
When this form of ``FetchContent_Populate()`` returns, the following
variables will be set in the scope of the caller:
``<lowercaseName>_POPULATED``
This will always be set to ``TRUE`` by the call.
``<lowercaseName>_SOURCE_DIR``
The location where the populated content can be found upon return.
``<lowercaseName>_BINARY_DIR``
A directory intended for use as a corresponding build directory.
The values of the three variables can also be retrieved from anywhere in the
project hierarchy using the :command:`FetchContent_GetProperties` command.
The implementation ensures that if the content has already been populated
in a previous CMake run, that content will be reused rather than repopulating
again. For the common case where population involves downloading content,
the cost of the download is only paid once. But note that it is an error to
call ``FetchContent_Populate(<name>)`` with the same ``<name>`` more than
once within a single CMake run. See :command:`FetchContent_GetProperties`
for how to determine if population of a ``<name>`` has already been
performed in the current run.
.. command:: FetchContent_GetProperties
When using saved content details, a call to
@@ -622,13 +591,15 @@ Commands
This command is rarely needed when using
:command:`FetchContent_MakeAvailable`. It is more commonly used as part of
implementing the following pattern with :command:`FetchContent_Populate`,
implementing the deprecated pattern with :command:`FetchContent_Populate`,
which ensures that the relevant variables will always be defined regardless
of whether or not the population has been performed elsewhere in the project
already:
.. code-block:: cmake
# WARNING: This pattern is deprecated, don't use it!
#
# Check if population has already been performed
FetchContent_GetProperties(depname)
if(NOT depname_POPULATED)
@@ -1060,16 +1031,7 @@ that all five projects are available on a company git server. The
GIT_TAG 7d9a17ad2c962aa13e2fbb8043fb6b8a
)
# This particular version of projD requires workarounds
FetchContent_GetProperties(projD)
if(NOT projd_POPULATED)
FetchContent_Populate(projD)
# Copy an additional/replacement file into the populated source
file(COPY someFile.c DESTINATION ${projd_SOURCE_DIR}/src)
add_subdirectory(${projd_SOURCE_DIR} ${projd_BINARY_DIR})
endif()
FetchContent_MakeAvailable(projD)
A few key points should be noted in the above:
@@ -1081,15 +1043,20 @@ A few key points should be noted in the above:
it is up to the higher level project to ensure that the details it does
define still make sense for the child projects.
- In the ``projA`` call to :command:`FetchContent_MakeAvailable`, ``projD``
is listed ahead of ``projB`` and ``projC`` to ensure that ``projA`` is in
control of how ``projD`` is populated.
is listed ahead of ``projB`` and ``projC``, so it will be populated before
either ``projB`` or ``projC``. It isn't required for ``projA`` to do this,
doing so ensures that ``projA`` fully controls the environment in which
``projD`` is brought into the build (directory properties are particularly
relevant).
- While ``projA`` defines content details for ``projE``, it does not need
to explicitly call ``FetchContent_MakeAvailable(projE)`` or
``FetchContent_Populate(projD)`` itself. Instead, it leaves that to the
child ``projB``. For higher level projects, it is often enough to just
define the override content details and leave the actual population to the
child projects. This saves repeating the same thing at each level of the
project hierarchy unnecessarily.
project hierarchy unnecessarily, but it should only be done if directory
properties set by dependencies are not expected to influence the population
of the shared dependency (``projE`` in this case).
Populating Content Without Adding It To The Build
"""""""""""""""""""""""""""""""""""""""""""""""""
@@ -1940,6 +1907,24 @@ function(FetchContent_Populate contentName)
endif()
if(ARGC EQUAL 1)
cmake_policy(GET CMP0169 cmp0169
PARENT_SCOPE # undocumented, do not use outside of CMake
)
if(NOT cmp0169 STREQUAL "OLD")
string(CONCAT msg
"Calling FetchContent_Populate(${contentName}) is deprecated, call "
"FetchContent_MakeAvailable(${contentName}) instead. "
"Policy CMP0169 can be set to OLD to allow "
"FetchContent_Populate(${contentName}) to be called directly for now, "
"but the ability to call it with declared details will be removed "
"completely in a future version."
)
if(cmp0169 STREQUAL "NEW")
message(FATAL_ERROR "${msg}")
else()
message(AUTHOR_WARNING "${msg}")
endif()
endif()
set(__doDirectArgs)
else()
cmake_policy(GET CMP0168 cmp0168
@@ -1952,6 +1937,26 @@ function(FetchContent_Populate contentName)
endif()
endif()
cmake_parse_arguments(PARSE_ARGV 0 __arg "" "" "")
set(__argsQuoted)
foreach(__item IN LISTS __arg_UNPARSED_ARGUMENTS __doDirectArgs)
string(APPEND __argsQuoted " [==[${__item}]==]")
endforeach()
cmake_language(EVAL CODE "__FetchContent_Populate(${__argsQuoted})")
string(TOLOWER ${contentName} contentNameLower)
foreach(var IN ITEMS SOURCE_DIR BINARY_DIR POPULATED)
set(var "${contentNameLower}_${var}")
if(DEFINED ${var})
set(${var} "${${var}}" PARENT_SCOPE)
endif()
endforeach()
endfunction()
function(__FetchContent_Populate contentName)
string(TOLOWER ${contentName} contentNameLower)
if(ARGN)
@@ -1963,7 +1968,6 @@ function(FetchContent_Populate contentName)
SOURCE_DIR "${CMAKE_CURRENT_BINARY_DIR}/${contentNameLower}-src"
BINARY_DIR "${CMAKE_CURRENT_BINARY_DIR}/${contentNameLower}-build"
${ARGN} # Could override any of the above ..._DIR variables
${__doDirectArgs}
)
# Pass source and binary dir variables back to the caller
@@ -2301,7 +2305,7 @@ macro(FetchContent_MakeAvailable)
FetchContent_GetProperties(${__cmake_contentName})
if(NOT ${__cmake_contentNameLower}_POPULATED)
FetchContent_Populate(${__cmake_contentName})
__FetchContent_Populate(${__cmake_contentName})
__FetchContent_setupFindPackageRedirection(${__cmake_contentName})
# Only try to call add_subdirectory() if the populated content

View File

@@ -518,6 +518,10 @@ class cmMakefile;
SELECT(POLICY, CMP0168, \
"FetchContent implements steps directly instead of through a " \
"sub-build.", \
3, 30, 0, cmPolicies::WARN) \
SELECT(POLICY, CMP0169, \
"FetchContent_Populate(depName) single-argument signature is " \
"deprecated.", \
3, 30, 0, cmPolicies::WARN)
#define CM_SELECT_ID(F, A1, A2, A3, A4, A5, A6) F(A1)

View File

@@ -0,0 +1 @@
1

View File

@@ -0,0 +1,10 @@
CMake Error at .*/Modules/FetchContent\.cmake:[0-9]+ \(message\):
Calling FetchContent_Populate\(t2\) is deprecated, call
FetchContent_MakeAvailable\(t2\) instead\. Policy CMP0169 can be set to OLD
to allow FetchContent_Populate\(t2\) to be called directly for now, but the
ability to call it with declared details will be removed completely in a
future version\.
Call Stack \(most recent call first\):
CMP0169\.cmake:[0-9]+ \(FetchContent_Populate\)
CMP0169-NEW\.cmake:[0-9]+ \(include\)
CMakeLists\.txt:[0-9]+ \(include\)

View File

@@ -0,0 +1,2 @@
Direct download
-- Configuring incomplete, errors occurred!

View File

@@ -0,0 +1,2 @@
cmake_policy(SET CMP0169 NEW)
include(CMP0169.cmake)

View File

@@ -0,0 +1,4 @@
Direct download
Declared download
-- Configuring done \([0-9]+\.[0-9]s\)
-- Generating done \([0-9]+\.[0-9]s\)

View File

@@ -0,0 +1,2 @@
cmake_policy(SET CMP0169 OLD)
include(CMP0169.cmake)

View File

@@ -0,0 +1,11 @@
CMake Warning \(dev\) at .*/Modules/FetchContent\.cmake:[0-9]+ \(message\):
Calling FetchContent_Populate\(t2\) is deprecated, call
FetchContent_MakeAvailable\(t2\) instead\. Policy CMP0169 can be set to OLD
to allow FetchContent_Populate\(t2\) to be called directly for now, but the
ability to call it with declared details will be removed completely in a
future version\.
Call Stack \(most recent call first\):
CMP0169\.cmake:[0-9]+ \(FetchContent_Populate\)
CMP0169-WARN\.cmake:[0-9]+ \(include\)
CMakeLists\.txt:[0-9]+ \(include\)
This warning is for project developers\. Use -Wno-dev to suppress it\.

View File

@@ -0,0 +1,4 @@
Direct download
Declared download
-- Configuring done \([0-9]+\.[0-9]s\)
-- Generating done \([0-9]+\.[0-9]s\)

View File

@@ -0,0 +1 @@
include(CMP0169.cmake)

View File

@@ -0,0 +1,14 @@
cmake_policy(SET CMP0168 NEW) # Faster, don't need to test with sub-build
include(FetchContent)
FetchContent_Populate(t1
DOWNLOAD_COMMAND ${CMAKE_COMMAND} -E echo "Direct download"
UPDATE_COMMAND ""
)
FetchContent_Declare(t2
DOWNLOAD_COMMAND ${CMAKE_COMMAND} -E echo "Declared download"
UPDATE_COMMAND ""
)
FetchContent_Populate(t2)

View File

@@ -0,0 +1,3 @@
cmake_minimum_required(VERSION 3.29)
project(${RunCMake_TEST} NONE)
include(${RunCMake_TEST}.cmake)

View File

@@ -0,0 +1,5 @@
include(RunCMake)
run_cmake(CMP0169-WARN)
run_cmake(CMP0169-OLD)
run_cmake(CMP0169-NEW)

View File

@@ -175,6 +175,7 @@ add_RunCMake_test(CMP0156 -DCMAKE_C_COMPILER_ID=${CMAKE_C_COMPILER_ID}
add_RunCMake_test(CMP0160)
add_RunCMake_test(CMP0163)
add_RunCMake_test(CMP0165)
add_RunCMake_test(CMP0169)
# The test for Policy 65 requires the use of the
# CMAKE_SHARED_LIBRARY_LINK_CXX_FLAGS variable, which both the VS and Xcode

View File

@@ -1,3 +1,5 @@
cmake_policy(SET CMP0169 OLD)
include(FetchContent)
# Test using saved details

View File

@@ -1,3 +1,5 @@
cmake_policy(SET CMP0169 OLD)
include(FetchContent)
# Test using saved details. We are re-using a SOURCE_DIR from a previous test

View File

@@ -1,3 +1,5 @@
cmake_policy(SET CMP0169 OLD)
include(FetchContent)
FetchContent_Declare(

View File

@@ -1,3 +1,5 @@
cmake_policy(SET CMP0169 OLD)
include(FetchContent)
# The file hash depends on the line endings used by git

View File

@@ -1,3 +1,5 @@
cmake_policy(SET CMP0169 OLD)
include(FetchContent)
FetchContent_Declare(

View File

@@ -1,3 +1,5 @@
cmake_policy(SET CMP0169 OLD)
include(FetchContent)
# Need to see the download command output

View File

@@ -1,3 +1,5 @@
cmake_policy(SET CMP0169 OLD)
include(FetchContent)
# First confirm properties are empty even before declare

View File

@@ -1,3 +1,5 @@
cmake_policy(SET CMP0169 OLD)
include(FetchContent)
FetchContent_Populate(t1)

View File

@@ -1,3 +1,5 @@
cmake_policy(SET CMP0169 OLD)
include(FetchContent)
# Need to see the download command output

View File

@@ -1,3 +1,5 @@
cmake_policy(SET CMP0169 OLD)
include(FetchContent)
FetchContent_Declare(

View File

@@ -1,3 +1,5 @@
cmake_policy(SET CMP0169 OLD)
include(FetchContent)
set(FETCHCONTENT_QUIET NO)

View File

@@ -3,6 +3,8 @@ unset(FETCHCONTENT_UPDATES_DISCONNECTED CACHE)
unset(FETCHCONTENT_QUIET CACHE)
unset(FETCHCONTENT_BASE_DIR CACHE)
cmake_policy(SET CMP0169 OLD)
include(FetchContent)
# Each of the cache entries should be defined and have the

View File

@@ -1,3 +1,5 @@
cmake_policy(SET CMP0169 OLD)
include(FetchContent)
set(CMAKE_EP_GIT_REMOTE_UPDATE_STRATEGY AAAA)

View File

@@ -1,3 +1,5 @@
cmake_policy(SET CMP0169 OLD)
include(FetchContent)
FetchContent_Populate(t1)

View File

@@ -1,3 +1,5 @@
cmake_policy(SET CMP0169 OLD)
include(FetchContent)
# Need to see the download command output