forked from boostorg/mp11
Remove local copy of FetchContent; use boost_fetch
This commit is contained in:
Peter Dimov
@@ -18,27 +18,28 @@ if(CMAKE_SOURCE_DIR STREQUAL CMAKE_CURRENT_SOURCE_DIR)
|
|||||||
|
|
||||||
# --target check
|
# --target check
|
||||||
|
|
||||||
# requires CMake 3.11 so we just carry it around
|
# `function` confuses FetchContent, sees empty CMAKE_CURRENT_LIST_DIR
|
||||||
include(cmake/FetchContent.cmake)
|
macro(fetch_and_include name)
|
||||||
|
|
||||||
message(STATUS "Fetching pdimov/mincmake")
|
message(STATUS "Fetching ${name}")
|
||||||
FetchContent_Populate(pdimov_mincmake QUIET GIT_REPOSITORY https://github.com/pdimov/mincmake GIT_TAG master)
|
|
||||||
include(${pdimov_mincmake_SOURCE_DIR}/cmake/boost_test.cmake)
|
|
||||||
|
|
||||||
message(STATUS "Fetching boostorg/assert")
|
file(DOWNLOAD
|
||||||
FetchContent_Populate(boostorg_assert QUIET GIT_REPOSITORY https://github.com/boostorg/assert GIT_TAG develop)
|
"https://raw.githubusercontent.com/pdimov/mincmake/master/${name}"
|
||||||
add_subdirectory(${boostorg_assert_SOURCE_DIR} ${boostorg_assert_BINARY_DIR})
|
"${CMAKE_BINARY_DIR}/fetch_and_include/${name}"
|
||||||
|
)
|
||||||
|
|
||||||
message(STATUS "Fetching boostorg/config")
|
include("${CMAKE_BINARY_DIR}/fetch_and_include/${name}")
|
||||||
FetchContent_Populate(boostorg_config QUIET GIT_REPOSITORY https://github.com/boostorg/config GIT_TAG develop)
|
|
||||||
add_subdirectory(${boostorg_config_SOURCE_DIR} ${boostorg_config_BINARY_DIR})
|
|
||||||
|
|
||||||
message(STATUS "Fetching boostorg/core")
|
endmacro()
|
||||||
FetchContent_Populate(boostorg_core QUIET GIT_REPOSITORY https://github.com/boostorg/core GIT_TAG develop)
|
|
||||||
add_subdirectory(${boostorg_core_SOURCE_DIR} ${boostorg_core_BINARY_DIR})
|
fetch_and_include(cmake/boost_fetch.cmake)
|
||||||
|
fetch_and_include(cmake/boost_test.cmake)
|
||||||
|
|
||||||
|
boost_fetch(boostorg/assert TAG develop)
|
||||||
|
boost_fetch(boostorg/config TAG develop)
|
||||||
|
boost_fetch(boostorg/core TAG develop)
|
||||||
|
|
||||||
enable_testing()
|
enable_testing()
|
||||||
|
|
||||||
add_custom_target(check COMMAND ${CMAKE_CTEST_COMMAND} --output-on-failure -C $<CONFIG>)
|
add_custom_target(check COMMAND ${CMAKE_CTEST_COMMAND} --output-on-failure -C $<CONFIG>)
|
||||||
|
|
||||||
# --target install
|
# --target install
|
||||||
|
|||||||
@@ -1,916 +0,0 @@
|
|||||||
# Distributed under the OSI-approved BSD 3-Clause License. See accompanying
|
|
||||||
# file Copyright.txt or https://cmake.org/licensing for details.
|
|
||||||
|
|
||||||
#[=======================================================================[.rst:
|
|
||||||
FetchContent
|
|
||||||
------------------
|
|
||||||
|
|
||||||
.. only:: html
|
|
||||||
|
|
||||||
.. contents::
|
|
||||||
|
|
||||||
Overview
|
|
||||||
^^^^^^^^
|
|
||||||
|
|
||||||
This module enables populating content at configure time via any method
|
|
||||||
supported by the :module:`ExternalProject` module. Whereas
|
|
||||||
:command:`ExternalProject_Add` downloads at build time, the
|
|
||||||
``FetchContent`` module makes content available immediately, allowing the
|
|
||||||
configure step to use the content in commands like :command:`add_subdirectory`,
|
|
||||||
:command:`include` or :command:`file` operations.
|
|
||||||
|
|
||||||
Content population details would normally be defined separately from the
|
|
||||||
command that performs the actual population. Projects should also
|
|
||||||
check whether the content has already been populated somewhere else in the
|
|
||||||
project hierarchy. Typical usage would look something like this:
|
|
||||||
|
|
||||||
.. code-block:: cmake
|
|
||||||
|
|
||||||
FetchContent_Declare(
|
|
||||||
googletest
|
|
||||||
GIT_REPOSITORY https://github.com/google/googletest.git
|
|
||||||
GIT_TAG release-1.8.0
|
|
||||||
)
|
|
||||||
|
|
||||||
FetchContent_GetProperties(googletest)
|
|
||||||
if(NOT googletest_POPULATED)
|
|
||||||
FetchContent_Populate(googletest)
|
|
||||||
add_subdirectory(${googletest_SOURCE_DIR} ${googletest_BINARY_DIR})
|
|
||||||
endif()
|
|
||||||
|
|
||||||
When using the above pattern with a hierarchical project arrangement,
|
|
||||||
projects at higher levels in the hierarchy are able to define or override
|
|
||||||
the population details of content specified anywhere lower in the project
|
|
||||||
hierarchy. The ability to detect whether content has already been
|
|
||||||
populated ensures that even if multiple child projects want certain content
|
|
||||||
to be available, the first one to populate it wins. The other child project
|
|
||||||
can simply make use of the already available content instead of repeating
|
|
||||||
the population for itself. See the
|
|
||||||
:ref:`Examples <fetch-content-examples>` section which demonstrates
|
|
||||||
this scenario.
|
|
||||||
|
|
||||||
The ``FetchContent`` module also supports defining and populating
|
|
||||||
content in a single call, with no check for whether the content has been
|
|
||||||
populated elsewhere in the project already. This is a more low level
|
|
||||||
operation and would not normally be the way the module is used, but it is
|
|
||||||
sometimes useful as part of implementing some higher level feature or to
|
|
||||||
populate some content in CMake's script mode.
|
|
||||||
|
|
||||||
|
|
||||||
Declaring Content Details
|
|
||||||
^^^^^^^^^^^^^^^^^^^^^^^^^
|
|
||||||
|
|
||||||
.. command:: FetchContent_Declare
|
|
||||||
|
|
||||||
.. code-block:: cmake
|
|
||||||
|
|
||||||
FetchContent_Declare(<name> <contentOptions>...)
|
|
||||||
|
|
||||||
The ``FetchContent_Declare()`` function records the options that describe
|
|
||||||
how to populate the specified content, but if such details have already
|
|
||||||
been recorded earlier in this project (regardless of where in the project
|
|
||||||
hierarchy), this and all later calls for the same content ``<name>`` are
|
|
||||||
ignored. This "first to record, wins" approach is what allows hierarchical
|
|
||||||
projects to have parent projects override content details of child projects.
|
|
||||||
|
|
||||||
The content ``<name>`` can be any string without spaces, but good practice
|
|
||||||
would be to use only letters, numbers and underscores. The name will be
|
|
||||||
treated case-insensitively and it should be obvious for the content it
|
|
||||||
represents, often being the name of the child project or the value given
|
|
||||||
to its top level :command:`project` command (if it is a CMake project).
|
|
||||||
For well-known public projects, the name should generally be the official
|
|
||||||
name of the project. Choosing an unusual name makes it unlikely that other
|
|
||||||
projects needing that same content will use the same name, leading to
|
|
||||||
the content being populated multiple times.
|
|
||||||
|
|
||||||
The ``<contentOptions>`` can be any of the download or update/patch options
|
|
||||||
that the :command:`ExternalProject_Add` command understands. The configure,
|
|
||||||
build, install and test steps are explicitly disabled and therefore options
|
|
||||||
related to them will be ignored. In most cases, ``<contentOptions>`` will
|
|
||||||
just be a couple of options defining the download method and method-specific
|
|
||||||
details like a commit tag or archive hash. For example:
|
|
||||||
|
|
||||||
.. code-block:: cmake
|
|
||||||
|
|
||||||
FetchContent_Declare(
|
|
||||||
googletest
|
|
||||||
GIT_REPOSITORY https://github.com/google/googletest.git
|
|
||||||
GIT_TAG release-1.8.0
|
|
||||||
)
|
|
||||||
|
|
||||||
FetchContent_Declare(
|
|
||||||
myCompanyIcons
|
|
||||||
URL https://intranet.mycompany.com/assets/iconset_1.12.tar.gz
|
|
||||||
URL_HASH 5588a7b18261c20068beabfb4f530b87
|
|
||||||
)
|
|
||||||
|
|
||||||
FetchContent_Declare(
|
|
||||||
myCompanyCertificates
|
|
||||||
SVN_REPOSITORY svn+ssh://svn.mycompany.com/srv/svn/trunk/certs
|
|
||||||
SVN_REVISION -r12345
|
|
||||||
)
|
|
||||||
|
|
||||||
Populating The Content
|
|
||||||
^^^^^^^^^^^^^^^^^^^^^^
|
|
||||||
|
|
||||||
.. command:: FetchContent_Populate
|
|
||||||
|
|
||||||
.. 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 construct a call to :command:`ExternalProject_Add` in a
|
|
||||||
private sub-build to perform the content population immediately. The
|
|
||||||
implementation of ``ExternalProject_Add()`` 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; ``<lcName>_POPULATED``, ``<lcName>_SOURCE_DIR`` and
|
|
||||||
``<lcName>_BINARY_DIR``, where ``<lcName>`` is the lowercased ``<name>``.
|
|
||||||
``<lcName>_POPULATED`` will always be set to ``True`` by the call.
|
|
||||||
``<lcName>_SOURCE_DIR`` is the location where the
|
|
||||||
content can be found upon return (it will have already been populated), while
|
|
||||||
``<lcName>_BINARY_DIR`` is a directory intended for use as a corresponding
|
|
||||||
build directory. The main use case for the two directory variables is to
|
|
||||||
call :command:`add_subdirectory` immediately after population, i.e.:
|
|
||||||
|
|
||||||
.. 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.
|
|
||||||
|
|
||||||
A number of cache variables influence the behavior of all content population
|
|
||||||
performed using details saved from a :command:`FetchContent_Declare` call:
|
|
||||||
|
|
||||||
``FETCHCONTENT_BASE_DIR``
|
|
||||||
In most cases, the saved details do not specify any options relating to the
|
|
||||||
directories to use for the internal sub-build, final source and build areas.
|
|
||||||
It is generally best to leave these decisions up to the ``FetchContent``
|
|
||||||
module to handle on the project's behalf. The ``FETCHCONTENT_BASE_DIR``
|
|
||||||
cache variable controls the point under which all content population
|
|
||||||
directories are collected, but in most cases developers would not need to
|
|
||||||
change this. The default location is ``${CMAKE_BINARY_DIR}/_deps``, but if
|
|
||||||
developers change this value, they should aim to keep the path short and
|
|
||||||
just below the top level of the build tree to avoid running into path
|
|
||||||
length problems on Windows.
|
|
||||||
|
|
||||||
``FETCHCONTENT_QUIET``
|
|
||||||
The logging output during population can be quite verbose, making the
|
|
||||||
configure stage quite noisy. This cache option (``ON`` by default) hides
|
|
||||||
all population output unless an error is encountered. If experiencing
|
|
||||||
problems with hung downloads, temporarily switching this option off may
|
|
||||||
help diagnose which content population is causing the issue.
|
|
||||||
|
|
||||||
``FETCHCONTENT_FULLY_DISCONNECTED``
|
|
||||||
When this option is enabled, no attempt is made to download or update
|
|
||||||
any content. It is assumed that all content has already been populated in
|
|
||||||
a previous run or the source directories have been pointed at existing
|
|
||||||
contents the developer has provided manually (using options described
|
|
||||||
further below). When the developer knows that no changes have been made to
|
|
||||||
any content details, turning this option ``ON`` can significantly speed up
|
|
||||||
the configure stage. It is ``OFF`` by default.
|
|
||||||
|
|
||||||
``FETCHCONTENT_UPDATES_DISCONNECTED``
|
|
||||||
This is a less severe download/update control compared to
|
|
||||||
``FETCHCONTENT_FULLY_DISCONNECTED``. Instead of bypassing all download and
|
|
||||||
update logic, the ``FETCHCONTENT_UPDATES_DISCONNECTED`` only disables the
|
|
||||||
update stage. Therefore, if content has not been downloaded previously,
|
|
||||||
it will still be downloaded when this option is enabled. This can speed up
|
|
||||||
the configure stage, but not as much as
|
|
||||||
``FETCHCONTENT_FULLY_DISCONNECTED``. It is ``OFF`` by default.
|
|
||||||
|
|
||||||
In addition to the above cache variables, the following cache variables are
|
|
||||||
also defined for each content name (``<ucName>`` is the uppercased value of
|
|
||||||
``<name>``):
|
|
||||||
|
|
||||||
``FETCHCONTENT_SOURCE_DIR_<ucName>``
|
|
||||||
If this is set, no download or update steps are performed for the specified
|
|
||||||
content and the ``<lcName>_SOURCE_DIR`` variable returned to the caller is
|
|
||||||
pointed at this location. This gives developers a way to have a separate
|
|
||||||
checkout of the content that they can modify freely without interference
|
|
||||||
from the build. The build simply uses that existing source, but it still
|
|
||||||
defines ``<lcName>_BINARY_DIR`` to point inside its own build area.
|
|
||||||
Developers are strongly encouraged to use this mechanism rather than
|
|
||||||
editing the sources populated in the default location, as changes to
|
|
||||||
sources in the default location can be lost when content population details
|
|
||||||
are changed by the project.
|
|
||||||
|
|
||||||
``FETCHCONTENT_UPDATES_DISCONNECTED_<ucName>``
|
|
||||||
This is the per-content equivalent of
|
|
||||||
``FETCHCONTENT_UPDATES_DISCONNECTED``. If the global option or this option
|
|
||||||
is ``ON``, then updates will be disabled for the named content.
|
|
||||||
Disabling updates for individual content can be useful for content whose
|
|
||||||
details rarely change, while still leaving other frequently changing
|
|
||||||
content with updates enabled.
|
|
||||||
|
|
||||||
|
|
||||||
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 favour 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):
|
|
||||||
|
|
||||||
.. code-block:: cmake
|
|
||||||
|
|
||||||
FetchContent_Populate( <name>
|
|
||||||
[QUIET]
|
|
||||||
[SUBBUILD_DIR <subBuildDir>]
|
|
||||||
[SOURCE_DIR <srcDir>]
|
|
||||||
[BINARY_DIR <binDir>]
|
|
||||||
...
|
|
||||||
)
|
|
||||||
|
|
||||||
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 ``<lcName>_SOURCE_DIR`` and ``<lcName>_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
|
|
||||||
``<lcName>_POPULATED`` variable is set in the caller's scope with this form.
|
|
||||||
|
|
||||||
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.
|
|
||||||
|
|
||||||
``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 global ``FETCHCONTENT_QUIET``
|
|
||||||
cache variable has no effect on ``FetchContent_Populate()`` calls where the
|
|
||||||
content details are provided directly.
|
|
||||||
|
|
||||||
``SUBBUILD_DIR``
|
|
||||||
The ``SUBBUILD_DIR`` argument can be provided to change the location of the
|
|
||||||
sub-build created to perform the population. The default value is
|
|
||||||
``${CMAKE_CURRENT_BINARY_DIR}/<lcName>-subbuild`` and it would be unusual
|
|
||||||
to need to override this default. If a relative path is specified, it will
|
|
||||||
be interpreted as relative to :variable:`CMAKE_CURRENT_BINARY_DIR`.
|
|
||||||
|
|
||||||
``SOURCE_DIR``, ``BINARY_DIR``
|
|
||||||
The ``SOURCE_DIR`` and ``BINARY_DIR`` arguments are supported by
|
|
||||||
:command:`ExternalProject_Add`, but different default values are used by
|
|
||||||
``FetchContent_Populate()``. ``SOURCE_DIR`` defaults to
|
|
||||||
``${CMAKE_CURRENT_BINARY_DIR}/<lcName>-src`` and ``BINARY_DIR`` defaults to
|
|
||||||
``${CMAKE_CURRENT_BINARY_DIR}/<lcName>-build``. If a relative path is
|
|
||||||
specified, it will be interpreted as relative to
|
|
||||||
:variable:`CMAKE_CURRENT_BINARY_DIR`.
|
|
||||||
|
|
||||||
In addition to the above explicit options, any other unrecognized options are
|
|
||||||
passed through unmodified to :command:`ExternalProject_Add` to perform the
|
|
||||||
download, patch and update steps. The following options are explicitly
|
|
||||||
prohibited (they are disabled by the ``FetchContent_Populate()`` command):
|
|
||||||
|
|
||||||
- ``CONFIGURE_COMMAND``
|
|
||||||
- ``BUILD_COMMAND``
|
|
||||||
- ``INSTALL_COMMAND``
|
|
||||||
- ``TEST_COMMAND``
|
|
||||||
|
|
||||||
If using ``FetchContent_Populate()`` within CMake's script mode, be aware
|
|
||||||
that the implementation sets up a sub-build which therefore requires a CMake
|
|
||||||
generator and build tool to be available. If these cannot be found by
|
|
||||||
default, then the :variable:`CMAKE_GENERATOR` and/or
|
|
||||||
:variable:`CMAKE_MAKE_PROGRAM` variables will need to be set appropriately
|
|
||||||
on the command line invoking the script.
|
|
||||||
|
|
||||||
|
|
||||||
Retrieve Population Properties
|
|
||||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
|
||||||
|
|
||||||
.. command:: FetchContent_GetProperties
|
|
||||||
|
|
||||||
When using saved content details, a call to :command:`FetchContent_Populate`
|
|
||||||
records information in global properties which can be queried at any time.
|
|
||||||
This information includes the source and binary directories associated with
|
|
||||||
the content and also whether or not the content population has been processed
|
|
||||||
during the current configure run.
|
|
||||||
|
|
||||||
.. code-block:: cmake
|
|
||||||
|
|
||||||
FetchContent_GetProperties( <name>
|
|
||||||
[SOURCE_DIR <srcDirVar>]
|
|
||||||
[BINARY_DIR <binDirVar>]
|
|
||||||
[POPULATED <doneVar>]
|
|
||||||
)
|
|
||||||
|
|
||||||
The ``SOURCE_DIR``, ``BINARY_DIR`` and ``POPULATED`` options can be used to
|
|
||||||
specify which properties should be retrieved. Each option accepts a value
|
|
||||||
which is the name of the variable in which to store that property. Most of
|
|
||||||
the time though, only ``<name>`` is given, in which case the call will then
|
|
||||||
set the same variables as a call to
|
|
||||||
:command:`FetchContent_Populate(name) <FetchContent_Populate>`. This allows
|
|
||||||
the following canonical pattern to be used, 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
|
|
||||||
|
|
||||||
FetchContent_GetProperties(foobar)
|
|
||||||
if(NOT foobar_POPULATED)
|
|
||||||
FetchContent_Populate(foobar)
|
|
||||||
|
|
||||||
# Set any custom variables, etc. here, then
|
|
||||||
# populate the content as part of this build
|
|
||||||
|
|
||||||
add_subdirectory(${foobar_SOURCE_DIR} ${foobar_BINARY_DIR})
|
|
||||||
endif()
|
|
||||||
|
|
||||||
The above pattern allows other parts of the overall project hierarchy to
|
|
||||||
re-use the same content and ensure that it is only populated once.
|
|
||||||
|
|
||||||
|
|
||||||
.. _`fetch-content-examples`:
|
|
||||||
|
|
||||||
Examples
|
|
||||||
^^^^^^^^
|
|
||||||
|
|
||||||
Consider a project hierarchy where ``projA`` is the top level project and it
|
|
||||||
depends on projects ``projB`` and ``projC``. Both ``projB`` and ``projC``
|
|
||||||
can be built standalone and they also both depend on another project
|
|
||||||
``projD``. For simplicity, this example will assume that all four projects
|
|
||||||
are available on a company git server. The ``CMakeLists.txt`` of each project
|
|
||||||
might have sections like the following:
|
|
||||||
|
|
||||||
*projA*:
|
|
||||||
|
|
||||||
.. code-block:: cmake
|
|
||||||
|
|
||||||
include(FetchContent)
|
|
||||||
FetchContent_Declare(
|
|
||||||
projB
|
|
||||||
GIT_REPOSITORY git@mycompany.com/git/projB.git
|
|
||||||
GIT_TAG 4a89dc7e24ff212a7b5167bef7ab079d
|
|
||||||
)
|
|
||||||
FetchContent_Declare(
|
|
||||||
projC
|
|
||||||
GIT_REPOSITORY git@mycompany.com/git/projC.git
|
|
||||||
GIT_TAG 4ad4016bd1d8d5412d135cf8ceea1bb9
|
|
||||||
)
|
|
||||||
FetchContent_Declare(
|
|
||||||
projD
|
|
||||||
GIT_REPOSITORY git@mycompany.com/git/projD.git
|
|
||||||
GIT_TAG origin/integrationBranch
|
|
||||||
)
|
|
||||||
|
|
||||||
FetchContent_GetProperties(projB)
|
|
||||||
if(NOT projb_POPULATED)
|
|
||||||
FetchContent_Populate(projB)
|
|
||||||
add_subdirectory(${projb_SOURCE_DIR} ${projb_BINARY_DIR})
|
|
||||||
endif()
|
|
||||||
|
|
||||||
FetchContent_GetProperties(projC)
|
|
||||||
if(NOT projc_POPULATED)
|
|
||||||
FetchContent_Populate(projC)
|
|
||||||
add_subdirectory(${projc_SOURCE_DIR} ${projc_BINARY_DIR})
|
|
||||||
endif()
|
|
||||||
|
|
||||||
*projB*:
|
|
||||||
|
|
||||||
.. code-block:: cmake
|
|
||||||
|
|
||||||
include(FetchContent)
|
|
||||||
FetchContent_Declare(
|
|
||||||
projD
|
|
||||||
GIT_REPOSITORY git@mycompany.com/git/projD.git
|
|
||||||
GIT_TAG 20b415f9034bbd2a2e8216e9a5c9e632
|
|
||||||
)
|
|
||||||
|
|
||||||
FetchContent_GetProperties(projD)
|
|
||||||
if(NOT projd_POPULATED)
|
|
||||||
FetchContent_Populate(projD)
|
|
||||||
add_subdirectory(${projd_SOURCE_DIR} ${projd_BINARY_DIR})
|
|
||||||
endif()
|
|
||||||
|
|
||||||
|
|
||||||
*projC*:
|
|
||||||
|
|
||||||
.. code-block:: cmake
|
|
||||||
|
|
||||||
include(FetchContent)
|
|
||||||
FetchContent_Declare(
|
|
||||||
projD
|
|
||||||
GIT_REPOSITORY git@mycompany.com/git/projD.git
|
|
||||||
GIT_TAG 7d9a17ad2c962aa13e2fbb8043fb6b8a
|
|
||||||
)
|
|
||||||
|
|
||||||
FetchContent_GetProperties(projD)
|
|
||||||
if(NOT projd_POPULATED)
|
|
||||||
FetchContent_Populate(projD)
|
|
||||||
add_subdirectory(${projd_SOURCE_DIR} ${projd_BINARY_DIR})
|
|
||||||
endif()
|
|
||||||
|
|
||||||
A few key points should be noted in the above:
|
|
||||||
|
|
||||||
- ``projB`` and ``projC`` define different content details for ``projD``,
|
|
||||||
but ``projA`` also defines a set of content details for ``projD`` and
|
|
||||||
because ``projA`` will define them first, the details from ``projB`` and
|
|
||||||
``projC`` will not be used. The override details defined by ``projA``
|
|
||||||
are not required to match either of those from ``projB`` or ``projC``, but
|
|
||||||
it is up to the higher level project to ensure that the details it does
|
|
||||||
define still make sense for the child projects.
|
|
||||||
- While ``projA`` defined content details for ``projD``, it did not need
|
|
||||||
to explicitly call ``FetchContent_Populate(projD)`` itself. Instead, it
|
|
||||||
leaves that to a child project to do (in this case it will be ``projB``
|
|
||||||
since it is added to the build ahead of ``projC``). If ``projA`` needed to
|
|
||||||
customize how the ``projD`` content was brought into the build as well
|
|
||||||
(e.g. define some CMake variables before calling
|
|
||||||
:command:`add_subdirectory` after populating), it would do the call to
|
|
||||||
``FetchContent_Populate()``, etc. just as it did for the ``projB`` and
|
|
||||||
``projC`` content. For higher level projects, it is usually 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.
|
|
||||||
- Even though ``projA`` is the top level project in this example, it still
|
|
||||||
checks whether ``projB`` and ``projC`` have already been populated before
|
|
||||||
going ahead to do those populations. This makes ``projA`` able to be more
|
|
||||||
easily incorporated as a child of some other higher level project in the
|
|
||||||
future if required. Always protect a call to
|
|
||||||
:command:`FetchContent_Populate` with a check to
|
|
||||||
:command:`FetchContent_GetProperties`, even in what may be considered a top
|
|
||||||
level project at the time.
|
|
||||||
|
|
||||||
|
|
||||||
The following example demonstrates how one might download and unpack a
|
|
||||||
firmware tarball using CMake's :manual:`script mode <cmake(1)>`. The call to
|
|
||||||
:command:`FetchContent_Populate` specifies all the content details and the
|
|
||||||
unpacked firmware will be placed in a ``firmware`` directory below the
|
|
||||||
current working directory.
|
|
||||||
|
|
||||||
*getFirmware.cmake*:
|
|
||||||
|
|
||||||
.. code-block:: cmake
|
|
||||||
|
|
||||||
# NOTE: Intended to be run in script mode with cmake -P
|
|
||||||
include(FetchContent)
|
|
||||||
FetchContent_Populate(
|
|
||||||
firmware
|
|
||||||
URL https://mycompany.com/assets/firmware-1.23-arm.tar.gz
|
|
||||||
URL_HASH MD5=68247684da89b608d466253762b0ff11
|
|
||||||
SOURCE_DIR firmware
|
|
||||||
)
|
|
||||||
|
|
||||||
#]=======================================================================]
|
|
||||||
|
|
||||||
|
|
||||||
set(__FetchContent_privateDir "${CMAKE_CURRENT_LIST_DIR}/FetchContent")
|
|
||||||
|
|
||||||
#=======================================================================
|
|
||||||
# Recording and retrieving content details for later population
|
|
||||||
#=======================================================================
|
|
||||||
|
|
||||||
# Internal use, projects must not call this directly. It is
|
|
||||||
# intended for use by FetchContent_Declare() only.
|
|
||||||
#
|
|
||||||
# Sets a content-specific global property (not meant for use
|
|
||||||
# outside of functions defined here in this file) which can later
|
|
||||||
# be retrieved using __FetchContent_getSavedDetails() with just the
|
|
||||||
# same content name. If there is already a value stored in the
|
|
||||||
# property, it is left unchanged and this call has no effect.
|
|
||||||
# This allows parent projects to define the content details,
|
|
||||||
# overriding anything a child project may try to set (properties
|
|
||||||
# are not cached between runs, so the first thing to set it in a
|
|
||||||
# build will be in control).
|
|
||||||
function(__FetchContent_declareDetails contentName)
|
|
||||||
|
|
||||||
string(TOLOWER ${contentName} contentNameLower)
|
|
||||||
set(propertyName "_FetchContent_${contentNameLower}_savedDetails")
|
|
||||||
get_property(alreadyDefined GLOBAL PROPERTY ${propertyName} DEFINED)
|
|
||||||
if(NOT alreadyDefined)
|
|
||||||
define_property(GLOBAL PROPERTY ${propertyName}
|
|
||||||
BRIEF_DOCS "Internal implementation detail of FetchContent_Populate()"
|
|
||||||
FULL_DOCS "Details used by FetchContent_Populate() for ${contentName}"
|
|
||||||
)
|
|
||||||
set_property(GLOBAL PROPERTY ${propertyName} ${ARGN})
|
|
||||||
endif()
|
|
||||||
|
|
||||||
endfunction()
|
|
||||||
|
|
||||||
|
|
||||||
# Internal use, projects must not call this directly. It is
|
|
||||||
# intended for use by the FetchContent_Declare() function.
|
|
||||||
#
|
|
||||||
# Retrieves details saved for the specified content in an
|
|
||||||
# earlier call to __FetchContent_declareDetails().
|
|
||||||
function(__FetchContent_getSavedDetails contentName outVar)
|
|
||||||
|
|
||||||
string(TOLOWER ${contentName} contentNameLower)
|
|
||||||
set(propertyName "_FetchContent_${contentNameLower}_savedDetails")
|
|
||||||
get_property(alreadyDefined GLOBAL PROPERTY ${propertyName} DEFINED)
|
|
||||||
if(NOT alreadyDefined)
|
|
||||||
message(FATAL_ERROR "No content details recorded for ${contentName}")
|
|
||||||
endif()
|
|
||||||
get_property(propertyValue GLOBAL PROPERTY ${propertyName})
|
|
||||||
set(${outVar} "${propertyValue}" PARENT_SCOPE)
|
|
||||||
|
|
||||||
endfunction()
|
|
||||||
|
|
||||||
|
|
||||||
# Saves population details of the content, sets defaults for the
|
|
||||||
# SOURCE_DIR and BUILD_DIR.
|
|
||||||
function(FetchContent_Declare contentName)
|
|
||||||
|
|
||||||
set(options "")
|
|
||||||
set(oneValueArgs SVN_REPOSITORY)
|
|
||||||
set(multiValueArgs "")
|
|
||||||
|
|
||||||
cmake_parse_arguments(ARG "${options}" "${oneValueArgs}" "${multiValueArgs}" ${ARGN})
|
|
||||||
|
|
||||||
unset(srcDirSuffix)
|
|
||||||
unset(svnRepoArgs)
|
|
||||||
if(ARG_SVN_REPOSITORY)
|
|
||||||
# Add a hash of the svn repository URL to the source dir. This works
|
|
||||||
# around the problem where if the URL changes, the download would
|
|
||||||
# fail because it tries to checkout/update rather than switch the
|
|
||||||
# old URL to the new one. We limit the hash to the first 7 characters
|
|
||||||
# so that the source path doesn't get overly long (which can be a
|
|
||||||
# problem on windows due to path length limits).
|
|
||||||
string(SHA1 urlSHA ${ARG_SVN_REPOSITORY})
|
|
||||||
string(SUBSTRING ${urlSHA} 0 7 urlSHA)
|
|
||||||
set(srcDirSuffix "-${urlSHA}")
|
|
||||||
set(svnRepoArgs SVN_REPOSITORY ${ARG_SVN_REPOSITORY})
|
|
||||||
endif()
|
|
||||||
|
|
||||||
string(TOLOWER ${contentName} contentNameLower)
|
|
||||||
__FetchContent_declareDetails(
|
|
||||||
${contentNameLower}
|
|
||||||
SOURCE_DIR "${FETCHCONTENT_BASE_DIR}/${contentNameLower}-src${srcDirSuffix}"
|
|
||||||
BINARY_DIR "${FETCHCONTENT_BASE_DIR}/${contentNameLower}-build"
|
|
||||||
${svnRepoArgs}
|
|
||||||
# List these last so they can override things we set above
|
|
||||||
${ARG_UNPARSED_ARGUMENTS}
|
|
||||||
)
|
|
||||||
|
|
||||||
endfunction()
|
|
||||||
|
|
||||||
|
|
||||||
#=======================================================================
|
|
||||||
# Set/get whether the specified content has been populated yet.
|
|
||||||
# The setter also records the source and binary dirs used.
|
|
||||||
#=======================================================================
|
|
||||||
|
|
||||||
# Internal use, projects must not call this directly. It is
|
|
||||||
# intended for use by the FetchContent_Populate() function to
|
|
||||||
# record when FetchContent_Populate() is called for a particular
|
|
||||||
# content name.
|
|
||||||
function(__FetchContent_setPopulated contentName sourceDir binaryDir)
|
|
||||||
|
|
||||||
string(TOLOWER ${contentName} contentNameLower)
|
|
||||||
set(prefix "_FetchContent_${contentNameLower}")
|
|
||||||
|
|
||||||
set(propertyName "${prefix}_sourceDir")
|
|
||||||
define_property(GLOBAL PROPERTY ${propertyName}
|
|
||||||
BRIEF_DOCS "Internal implementation detail of FetchContent_Populate()"
|
|
||||||
FULL_DOCS "Details used by FetchContent_Populate() for ${contentName}"
|
|
||||||
)
|
|
||||||
set_property(GLOBAL PROPERTY ${propertyName} ${sourceDir})
|
|
||||||
|
|
||||||
set(propertyName "${prefix}_binaryDir")
|
|
||||||
define_property(GLOBAL PROPERTY ${propertyName}
|
|
||||||
BRIEF_DOCS "Internal implementation detail of FetchContent_Populate()"
|
|
||||||
FULL_DOCS "Details used by FetchContent_Populate() for ${contentName}"
|
|
||||||
)
|
|
||||||
set_property(GLOBAL PROPERTY ${propertyName} ${binaryDir})
|
|
||||||
|
|
||||||
set(propertyName "${prefix}_populated")
|
|
||||||
define_property(GLOBAL PROPERTY ${propertyName}
|
|
||||||
BRIEF_DOCS "Internal implementation detail of FetchContent_Populate()"
|
|
||||||
FULL_DOCS "Details used by FetchContent_Populate() for ${contentName}"
|
|
||||||
)
|
|
||||||
set_property(GLOBAL PROPERTY ${propertyName} True)
|
|
||||||
|
|
||||||
endfunction()
|
|
||||||
|
|
||||||
|
|
||||||
# Set variables in the calling scope for any of the retrievable
|
|
||||||
# properties. If no specific properties are requested, variables
|
|
||||||
# will be set for all retrievable properties.
|
|
||||||
#
|
|
||||||
# This function is intended to also be used by projects as the canonical
|
|
||||||
# way to detect whether they should call FetchContent_Populate()
|
|
||||||
# and pull the populated source into the build with add_subdirectory(),
|
|
||||||
# if they are using the populated content in that way.
|
|
||||||
function(FetchContent_GetProperties contentName)
|
|
||||||
|
|
||||||
string(TOLOWER ${contentName} contentNameLower)
|
|
||||||
|
|
||||||
set(options "")
|
|
||||||
set(oneValueArgs SOURCE_DIR BINARY_DIR POPULATED)
|
|
||||||
set(multiValueArgs "")
|
|
||||||
|
|
||||||
cmake_parse_arguments(ARG "${options}" "${oneValueArgs}" "${multiValueArgs}" ${ARGN})
|
|
||||||
|
|
||||||
if(NOT ARG_SOURCE_DIR AND
|
|
||||||
NOT ARG_BINARY_DIR AND
|
|
||||||
NOT ARG_POPULATED)
|
|
||||||
# No specific properties requested, provide them all
|
|
||||||
set(ARG_SOURCE_DIR ${contentNameLower}_SOURCE_DIR)
|
|
||||||
set(ARG_BINARY_DIR ${contentNameLower}_BINARY_DIR)
|
|
||||||
set(ARG_POPULATED ${contentNameLower}_POPULATED)
|
|
||||||
endif()
|
|
||||||
|
|
||||||
set(prefix "_FetchContent_${contentNameLower}")
|
|
||||||
|
|
||||||
if(ARG_SOURCE_DIR)
|
|
||||||
set(propertyName "${prefix}_sourceDir")
|
|
||||||
get_property(value GLOBAL PROPERTY ${propertyName})
|
|
||||||
if(value)
|
|
||||||
set(${ARG_SOURCE_DIR} ${value} PARENT_SCOPE)
|
|
||||||
endif()
|
|
||||||
endif()
|
|
||||||
|
|
||||||
if(ARG_BINARY_DIR)
|
|
||||||
set(propertyName "${prefix}_binaryDir")
|
|
||||||
get_property(value GLOBAL PROPERTY ${propertyName})
|
|
||||||
if(value)
|
|
||||||
set(${ARG_BINARY_DIR} ${value} PARENT_SCOPE)
|
|
||||||
endif()
|
|
||||||
endif()
|
|
||||||
|
|
||||||
if(ARG_POPULATED)
|
|
||||||
set(propertyName "${prefix}_populated")
|
|
||||||
get_property(value GLOBAL PROPERTY ${propertyName} DEFINED)
|
|
||||||
set(${ARG_POPULATED} ${value} PARENT_SCOPE)
|
|
||||||
endif()
|
|
||||||
|
|
||||||
endfunction()
|
|
||||||
|
|
||||||
|
|
||||||
#=======================================================================
|
|
||||||
# Performing the population
|
|
||||||
#=======================================================================
|
|
||||||
|
|
||||||
# The value of contentName will always have been lowercased by the caller.
|
|
||||||
# All other arguments are assumed to be options that are understood by
|
|
||||||
# ExternalProject_Add(), except for QUIET and SUBBUILD_DIR.
|
|
||||||
function(__FetchContent_directPopulate contentName)
|
|
||||||
|
|
||||||
set(options
|
|
||||||
QUIET
|
|
||||||
)
|
|
||||||
set(oneValueArgs
|
|
||||||
SUBBUILD_DIR
|
|
||||||
SOURCE_DIR
|
|
||||||
BINARY_DIR
|
|
||||||
# Prevent the following from being passed through
|
|
||||||
CONFIGURE_COMMAND
|
|
||||||
BUILD_COMMAND
|
|
||||||
INSTALL_COMMAND
|
|
||||||
TEST_COMMAND
|
|
||||||
)
|
|
||||||
set(multiValueArgs "")
|
|
||||||
|
|
||||||
cmake_parse_arguments(ARG "${options}" "${oneValueArgs}" "${multiValueArgs}" ${ARGN})
|
|
||||||
|
|
||||||
if(NOT ARG_SUBBUILD_DIR)
|
|
||||||
message(FATAL_ERROR "Internal error: SUBBUILD_DIR not set")
|
|
||||||
elseif(NOT IS_ABSOLUTE "${ARG_SUBBUILD_DIR}")
|
|
||||||
set(ARG_SUBBUILD_DIR "${CMAKE_CURRENT_BINARY_DIR}/${ARG_SUBBUILD_DIR}")
|
|
||||||
endif()
|
|
||||||
|
|
||||||
if(NOT ARG_SOURCE_DIR)
|
|
||||||
message(FATAL_ERROR "Internal error: SOURCE_DIR not set")
|
|
||||||
elseif(NOT IS_ABSOLUTE "${ARG_SOURCE_DIR}")
|
|
||||||
set(ARG_SOURCE_DIR "${CMAKE_CURRENT_BINARY_DIR}/${ARG_SOURCE_DIR}")
|
|
||||||
endif()
|
|
||||||
|
|
||||||
if(NOT ARG_BINARY_DIR)
|
|
||||||
message(FATAL_ERROR "Internal error: BINARY_DIR not set")
|
|
||||||
elseif(NOT IS_ABSOLUTE "${ARG_BINARY_DIR}")
|
|
||||||
set(ARG_BINARY_DIR "${CMAKE_CURRENT_BINARY_DIR}/${ARG_BINARY_DIR}")
|
|
||||||
endif()
|
|
||||||
|
|
||||||
# Ensure the caller can know where to find the source and build directories
|
|
||||||
# with some convenient variables. Doing this here ensures the caller sees
|
|
||||||
# the correct result in the case where the default values are overridden by
|
|
||||||
# the content details set by the project.
|
|
||||||
set(${contentName}_SOURCE_DIR "${ARG_SOURCE_DIR}" PARENT_SCOPE)
|
|
||||||
set(${contentName}_BINARY_DIR "${ARG_BINARY_DIR}" PARENT_SCOPE)
|
|
||||||
|
|
||||||
# The unparsed arguments may contain spaces, so build up ARG_EXTRA
|
|
||||||
# in such a way that it correctly substitutes into the generated
|
|
||||||
# CMakeLists.txt file with each argument quoted.
|
|
||||||
unset(ARG_EXTRA)
|
|
||||||
foreach(arg IN LISTS ARG_UNPARSED_ARGUMENTS)
|
|
||||||
set(ARG_EXTRA "${ARG_EXTRA} \"${arg}\"")
|
|
||||||
endforeach()
|
|
||||||
|
|
||||||
# Hide output if requested, but save it to a variable in case there's an
|
|
||||||
# error so we can show the output upon failure. When not quiet, don't
|
|
||||||
# capture the output to a variable because the user may want to see the
|
|
||||||
# output as it happens (e.g. progress during long downloads). Combine both
|
|
||||||
# stdout and stderr in the one capture variable so the output stays in order.
|
|
||||||
if (ARG_QUIET)
|
|
||||||
set(outputOptions
|
|
||||||
OUTPUT_VARIABLE capturedOutput
|
|
||||||
ERROR_VARIABLE capturedOutput
|
|
||||||
)
|
|
||||||
else()
|
|
||||||
set(capturedOutput)
|
|
||||||
set(outputOptions)
|
|
||||||
message(STATUS "Populating ${contentName}")
|
|
||||||
endif()
|
|
||||||
|
|
||||||
if(CMAKE_GENERATOR)
|
|
||||||
set(generatorOpts "-G${CMAKE_GENERATOR}")
|
|
||||||
if(CMAKE_GENERATOR_PLATFORM)
|
|
||||||
list(APPEND generatorOpts "-A${CMAKE_GENERATOR_PLATFORM}")
|
|
||||||
endif()
|
|
||||||
if(CMAKE_GENERATOR_TOOLSET)
|
|
||||||
list(APPEND generatorOpts "-T${CMAKE_GENERATOR_TOOLSET}")
|
|
||||||
endif()
|
|
||||||
|
|
||||||
if(CMAKE_MAKE_PROGRAM)
|
|
||||||
list(APPEND generatorOpts "-DCMAKE_MAKE_PROGRAM:FILEPATH=${CMAKE_MAKE_PROGRAM}")
|
|
||||||
endif()
|
|
||||||
|
|
||||||
else()
|
|
||||||
# Likely we've been invoked via CMake's script mode where no
|
|
||||||
# generator is set (and hence CMAKE_MAKE_PROGRAM could not be
|
|
||||||
# trusted even if provided). We will have to rely on being
|
|
||||||
# able to find the default generator and build tool.
|
|
||||||
unset(generatorOpts)
|
|
||||||
endif()
|
|
||||||
|
|
||||||
# Create and build a separate CMake project to carry out the population.
|
|
||||||
# If we've already previously done these steps, they will not cause
|
|
||||||
# anything to be updated, so extra rebuilds of the project won't occur.
|
|
||||||
# Make sure to pass through CMAKE_MAKE_PROGRAM in case the main project
|
|
||||||
# has this set to something not findable on the PATH.
|
|
||||||
configure_file("${__FetchContent_privateDir}/CMakeLists.cmake.in"
|
|
||||||
"${ARG_SUBBUILD_DIR}/CMakeLists.txt")
|
|
||||||
execute_process(
|
|
||||||
COMMAND ${CMAKE_COMMAND} ${generatorOpts} .
|
|
||||||
RESULT_VARIABLE result
|
|
||||||
${outputOptions}
|
|
||||||
WORKING_DIRECTORY "${ARG_SUBBUILD_DIR}"
|
|
||||||
)
|
|
||||||
if(result)
|
|
||||||
if(capturedOutput)
|
|
||||||
message("${capturedOutput}")
|
|
||||||
endif()
|
|
||||||
message(FATAL_ERROR "CMake step for ${contentName} failed: ${result}")
|
|
||||||
endif()
|
|
||||||
execute_process(
|
|
||||||
COMMAND ${CMAKE_COMMAND} --build .
|
|
||||||
RESULT_VARIABLE result
|
|
||||||
${outputOptions}
|
|
||||||
WORKING_DIRECTORY "${ARG_SUBBUILD_DIR}"
|
|
||||||
)
|
|
||||||
if(result)
|
|
||||||
if(capturedOutput)
|
|
||||||
message("${capturedOutput}")
|
|
||||||
endif()
|
|
||||||
message(FATAL_ERROR "Build step for ${contentName} failed: ${result}")
|
|
||||||
endif()
|
|
||||||
|
|
||||||
endfunction()
|
|
||||||
|
|
||||||
|
|
||||||
option(FETCHCONTENT_FULLY_DISCONNECTED "Disables all attempts to download or update content and assumes source dirs already exist")
|
|
||||||
option(FETCHCONTENT_UPDATES_DISCONNECTED "Enables UPDATE_DISCONNECTED behavior for all content population")
|
|
||||||
option(FETCHCONTENT_QUIET "Enables QUIET option for all content population" ON)
|
|
||||||
set(FETCHCONTENT_BASE_DIR "${CMAKE_BINARY_DIR}/_deps" CACHE PATH "Directory under which to collect all populated content")
|
|
||||||
|
|
||||||
# Populate the specified content using details stored from
|
|
||||||
# an earlier call to FetchContent_Declare().
|
|
||||||
function(FetchContent_Populate contentName)
|
|
||||||
|
|
||||||
if(NOT contentName)
|
|
||||||
message(FATAL_ERROR "Empty contentName not allowed for FetchContent_Populate()")
|
|
||||||
endif()
|
|
||||||
|
|
||||||
string(TOLOWER ${contentName} contentNameLower)
|
|
||||||
|
|
||||||
if(ARGN)
|
|
||||||
# This is the direct population form with details fully specified
|
|
||||||
# as part of the call, so we already have everything we need
|
|
||||||
__FetchContent_directPopulate(
|
|
||||||
${contentNameLower}
|
|
||||||
SUBBUILD_DIR "${CMAKE_CURRENT_BINARY_DIR}/${contentNameLower}-subbuild"
|
|
||||||
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
|
|
||||||
)
|
|
||||||
|
|
||||||
# Pass source and binary dir variables back to the caller
|
|
||||||
set(${contentNameLower}_SOURCE_DIR "${${contentNameLower}_SOURCE_DIR}" PARENT_SCOPE)
|
|
||||||
set(${contentNameLower}_BINARY_DIR "${${contentNameLower}_BINARY_DIR}" PARENT_SCOPE)
|
|
||||||
|
|
||||||
# Don't set global properties, or record that we did this population, since
|
|
||||||
# this was a direct call outside of the normal declared details form.
|
|
||||||
# We only want to save values in the global properties for content that
|
|
||||||
# honours the hierarchical details mechanism so that projects are not
|
|
||||||
# robbed of the ability to override details set in nested projects.
|
|
||||||
return()
|
|
||||||
endif()
|
|
||||||
|
|
||||||
# No details provided, so assume they were saved from an earlier call
|
|
||||||
# to FetchContent_Declare(). Do a check that we haven't already
|
|
||||||
# populated this content before in case the caller forgot to check.
|
|
||||||
FetchContent_GetProperties(${contentName})
|
|
||||||
if(${contentNameLower}_POPULATED)
|
|
||||||
message(FATAL_ERROR "Content ${contentName} already populated in ${${contentNameLower}_SOURCE_DIR}")
|
|
||||||
endif()
|
|
||||||
|
|
||||||
string(TOUPPER ${contentName} contentNameUpper)
|
|
||||||
set(FETCHCONTENT_SOURCE_DIR_${contentNameUpper}
|
|
||||||
"${FETCHCONTENT_SOURCE_DIR_${contentNameUpper}}"
|
|
||||||
CACHE PATH "When not empty, overrides where to find pre-populated content for ${contentName}")
|
|
||||||
|
|
||||||
if(FETCHCONTENT_SOURCE_DIR_${contentNameUpper})
|
|
||||||
# The source directory has been explicitly provided in the cache,
|
|
||||||
# so no population is required
|
|
||||||
set(${contentNameLower}_SOURCE_DIR "${FETCHCONTENT_SOURCE_DIR_${contentNameUpper}}")
|
|
||||||
set(${contentNameLower}_BINARY_DIR "${FETCHCONTENT_BASE_DIR}/${contentNameLower}-build")
|
|
||||||
|
|
||||||
elseif(FETCHCONTENT_FULLY_DISCONNECTED)
|
|
||||||
# Bypass population and assume source is already there from a previous run
|
|
||||||
set(${contentNameLower}_SOURCE_DIR "${FETCHCONTENT_BASE_DIR}/${contentNameLower}-src")
|
|
||||||
set(${contentNameLower}_BINARY_DIR "${FETCHCONTENT_BASE_DIR}/${contentNameLower}-build")
|
|
||||||
|
|
||||||
else()
|
|
||||||
# Support both a global "disconnect all updates" and a per-content
|
|
||||||
# update test (either one being set disables updates for this content).
|
|
||||||
option(FETCHCONTENT_UPDATES_DISCONNECTED_${contentNameUpper}
|
|
||||||
"Enables UPDATE_DISCONNECTED behavior just for population of ${contentName}")
|
|
||||||
if(FETCHCONTENT_UPDATES_DISCONNECTED OR
|
|
||||||
FETCHCONTENT_UPDATES_DISCONNECTED_${contentNameUpper})
|
|
||||||
set(disconnectUpdates True)
|
|
||||||
else()
|
|
||||||
set(disconnectUpdates False)
|
|
||||||
endif()
|
|
||||||
|
|
||||||
if(FETCHCONTENT_QUIET)
|
|
||||||
set(quietFlag QUIET)
|
|
||||||
else()
|
|
||||||
unset(quietFlag)
|
|
||||||
endif()
|
|
||||||
|
|
||||||
__FetchContent_getSavedDetails(${contentName} contentDetails)
|
|
||||||
if("${contentDetails}" STREQUAL "")
|
|
||||||
message(FATAL_ERROR "No details have been set for content: ${contentName}")
|
|
||||||
endif()
|
|
||||||
|
|
||||||
__FetchContent_directPopulate(
|
|
||||||
${contentNameLower}
|
|
||||||
${quietFlag}
|
|
||||||
UPDATE_DISCONNECTED ${disconnectUpdates}
|
|
||||||
SUBBUILD_DIR "${FETCHCONTENT_BASE_DIR}/${contentNameLower}-subbuild"
|
|
||||||
SOURCE_DIR "${FETCHCONTENT_BASE_DIR}/${contentNameLower}-src"
|
|
||||||
BINARY_DIR "${FETCHCONTENT_BASE_DIR}/${contentNameLower}-build"
|
|
||||||
# Put the saved details last so they can override any of the
|
|
||||||
# the options we set above (this can include SOURCE_DIR or
|
|
||||||
# BUILD_DIR)
|
|
||||||
${contentDetails}
|
|
||||||
)
|
|
||||||
endif()
|
|
||||||
|
|
||||||
__FetchContent_setPopulated(
|
|
||||||
${contentName}
|
|
||||||
${${contentNameLower}_SOURCE_DIR}
|
|
||||||
${${contentNameLower}_BINARY_DIR}
|
|
||||||
)
|
|
||||||
|
|
||||||
# Pass variables back to the caller. The variables passed back here
|
|
||||||
# must match what FetchContent_GetProperties() sets when it is called
|
|
||||||
# with just the content name.
|
|
||||||
set(${contentNameLower}_SOURCE_DIR "${${contentNameLower}_SOURCE_DIR}" PARENT_SCOPE)
|
|
||||||
set(${contentNameLower}_BINARY_DIR "${${contentNameLower}_BINARY_DIR}" PARENT_SCOPE)
|
|
||||||
set(${contentNameLower}_POPULATED True PARENT_SCOPE)
|
|
||||||
|
|
||||||
endfunction()
|
|
||||||
@@ -1,21 +0,0 @@
|
|||||||
# Distributed under the OSI-approved BSD 3-Clause License. See accompanying
|
|
||||||
# file Copyright.txt or https://cmake.org/licensing for details.
|
|
||||||
|
|
||||||
cmake_minimum_required(VERSION ${CMAKE_VERSION})
|
|
||||||
|
|
||||||
# We name the project and the target for the ExternalProject_Add() call
|
|
||||||
# to something that will highlight to the user what we are working on if
|
|
||||||
# something goes wrong and an error message is produced.
|
|
||||||
|
|
||||||
project(${contentName}-populate NONE)
|
|
||||||
|
|
||||||
include(ExternalProject)
|
|
||||||
ExternalProject_Add(${contentName}-populate
|
|
||||||
${ARG_EXTRA}
|
|
||||||
SOURCE_DIR "${ARG_SOURCE_DIR}"
|
|
||||||
BINARY_DIR "${ARG_BINARY_DIR}"
|
|
||||||
CONFIGURE_COMMAND ""
|
|
||||||
BUILD_COMMAND ""
|
|
||||||
INSTALL_COMMAND ""
|
|
||||||
TEST_COMMAND ""
|
|
||||||
)
|
|
||||||
Reference in New Issue
Block a user