reactos/CMake
1
0
Fork 0
mirror of https://github.com/reactos/CMake.git synced 2024-11-23 19:49:51 +00:00
Code Issues Actions Packages Projects Releases Wiki Activity
b551beb6fa
CMake/Modules/FetchContent.cmake
Jean-Christophe Fillion-Robin b551beb6fa
FetchContent: Support use of the module before "project()" command 
Co-authored-by: Craig Scott <craig.scott@crascit.com>
Co-authored-by: Brad King <brad.king@kitware.com>
2017-11-07 09:50:02 -05:00

917 lines
37 KiB
CMake
Raw Blame History

# 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()
Reference in New Issue View Git Blame Copy Permalink