# Distributed under the OSI-approved BSD 3-Clause License. See accompanying # file Copyright.txt or https://cmake.org/licensing for details. #[=======================================================================[.rst: FetchContent ------------------ .. versionadded:: 3.11 .. only:: html .. contents:: .. note:: The :guide:`Using Dependencies Guide` provides a high-level introduction to this general topic. It provides a broader overview of where the ``FetchContent`` module fits into the bigger picture, including its relationship to the :command:`find_package` command. The guide is recommended pre-reading before moving on to the details below. 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 should be defined separately from the command that performs the actual population. This separation ensures that all the dependency details are defined before anything might try to use them to populate content. This is particularly important in more complex project hierarchies where dependencies may be shared between multiple projects. The following shows a typical example of declaring content details for some dependencies and then ensuring they are populated with a separate call: .. code-block:: cmake FetchContent_Declare( googletest GIT_REPOSITORY https://github.com/google/googletest.git GIT_TAG 703bd9caab50b139428cea1aaff9974ebee5742e # release-1.10.0 ) FetchContent_Declare( myCompanyIcons URL https://intranet.mycompany.com/assets/iconset_1.12.tar.gz URL_HASH MD5=5588a7b18261c20068beabfb4f530b87 ) FetchContent_MakeAvailable(googletest myCompanyIcons) The :command:`FetchContent_MakeAvailable` command ensures the named dependencies have been populated, either by an earlier call, or by populating them itself. When performing the population, it will also add them to the main build, if possible, so that the main build can use the populated projects' targets, etc. See the command's documentation for how these steps are performed. When using a hierarchical project arrangement, projects at higher levels in the hierarchy are able to override the declared details of content specified anywhere lower in the project hierarchy. The first details to be declared for a given dependency take precedence, regardless of where in the project hierarchy that occurs. Similarly, the first call that tries to populate a dependency "wins", with subsequent populations reusing the result of the first instead of repeating the population again. See the :ref:`Examples ` which demonstrate 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 already. This should not be done in projects, but may be appropriate for populating content in :ref:`CMake script mode