|
|
@@ -0,0 +1,916 @@
|
|
|
+# 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()
|
Fangjun Kuang