FetchContent¶
New in version 3.11.
Note
The 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 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 ExternalProject module. Whereas
ExternalProject_Add() downloads at build time, the
FetchContent module makes content available immediately, allowing the
configure step to use the content in commands like add_subdirectory(),
include() or 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:
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 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 Examples which demonstrate this scenario.
In some cases, the main project may need to have more precise control over
the population, or it may be required to explicitly define the population
steps in a way that cannot be captured by the declared details alone.
For such situations, the lower level FetchContent_GetProperties() and
FetchContent_Populate() commands can be used. These lack the richer
features provided by FetchContent_MakeAvailable() though, so their
direct use should be considered a last resort. The typical pattern of such
custom steps looks like this:
# NOTE: Where possible, prefer to use FetchContent_MakeAvailable()
# instead of custom logic like this
# Check if population has already been performed
FetchContent_GetProperties(depname)
if(NOT depname_POPULATED)
# Fetch the content using previously declared details
FetchContent_Populate(depname)
# Set custom variables, policies, etc.
# ...
# Bring the populated content into the build
add_subdirectory(${depname_SOURCE_DIR} ${depname_BINARY_DIR})
endif()
The FetchContent module also supports defining and populating
content in a single call, with no check for whether the content has been
populated elsewhere already. This should not be done in projects, but may
be appropriate for populating content in CMake's script mode.
See FetchContent_Populate() for details.
Commands¶
- FetchContent_Declare¶
FetchContent_Declare( <name> <contentOptions>... [SYSTEM] [OVERRIDE_FIND_PACKAGE | FIND_PACKAGE_ARGS args...] )
The
FetchContent_Declare()function records the options that describe how to populate the specified content. 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 levelproject()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, update or patch options that theExternalProject_Add()command understands. The configure, build, install and test steps are explicitly disabled and therefore options related to them will be ignored. TheSOURCE_SUBDIRoption is an exception, seeFetchContent_MakeAvailable()for details on how that affects behavior.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: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_Declare( myCompanyCertificates SVN_REPOSITORY svn+ssh://svn.mycompany.com/srv/svn/trunk/certs SVN_REVISION -r12345 )
Where contents are being fetched from a remote location and you do not control that server, it is advisable to use a hash for
GIT_TAGrather than a branch or tag name. A commit hash is more secure and helps to confirm that the downloaded contents are what you expected.Changed in version 3.14: Commands for the download, update or patch steps can access the terminal. This may be needed for things like password prompts or real-time display of command progress.
New in version 3.22: The
CMAKE_TLS_VERIFY,CMAKE_TLS_CAINFO,CMAKE_NETRCandCMAKE_NETRC_FILEvariables now provide the defaults for their corresponding content options, just like they do forExternalProject_Add(). Previously, these variables were ignored by theFetchContentmodule.New in version 3.24:
FIND_PACKAGE_ARGSThis option is for scenarios where the
FetchContent_MakeAvailable()command may first try a call tofind_package()to satisfy the dependency for<name>. By default, such a call would be simplyfind_package(<name>), butFIND_PACKAGE_ARGScan be used to provide additional arguments to be appended after the<name>.FIND_PACKAGE_ARGScan also be given with nothing after it, which indicates thatfind_package()can still be called ifFETCHCONTENT_TRY_FIND_PACKAGE_MODEis set toOPT_INor is not set.Everything after the
FIND_PACKAGE_ARGSkeyword is appended to thefind_package()call, so all other<contentOptions>must come before theFIND_PACKAGE_ARGSkeyword. If theCMAKE_FIND_PACKAGE_TARGETS_GLOBALvariable is set to true at the timeFetchContent_Declare()is called, aGLOBALkeyword will be appended to thefind_package()arguments if it was not already specified. It will also be appended ifFIND_PACKAGE_ARGSwas not given, butFETCHCONTENT_TRY_FIND_PACKAGE_MODEwas set toALWAYS.OVERRIDE_FIND_PACKAGEcannot be used whenFIND_PACKAGE_ARGSis given.Dependency Providers discusses another way that
FetchContent_MakeAvailable()calls can be redirected.FIND_PACKAGE_ARGSis intended for project control, whereas dependency providers allow users to override project behavior.OVERRIDE_FIND_PACKAGEWhen a
FetchContent_Declare(<name> ...)call includes this option, subsequent calls tofind_package(<name> ...)will ensure thatFetchContent_MakeAvailable(<name>)has been called, then use the config package files in theCMAKE_FIND_PACKAGE_REDIRECTS_DIRdirectory (which are usually created byFetchContent_MakeAvailable()). This effectively makesFetchContent_MakeAvailable()overridefind_package()for the named dependency, allowing the former to satisfy the package requirements of the latter.FIND_PACKAGE_ARGScannot be used whenOVERRIDE_FIND_PACKAGEis given.If a dependency provider has been set and the project calls
find_package()for the<name>dependency,OVERRIDE_FIND_PACKAGEwill not prevent the provider from seeing that call. Dependency providers always have the opportunity to intercept any direct call tofind_package(), except if that call contains theBYPASS_PROVIDERoption.
New in version 3.25:
SYSTEMIf the
SYSTEMargument is provided, theSYSTEMdirectory property of a subdirectory added byFetchContent_MakeAvailable()will be set to true. This will affect non-imported targets created as part of that command. See theSYSTEMtarget property documentation for a more detailed discussion of the effects.
- FetchContent_MakeAvailable¶
New in version 3.14.
FetchContent_MakeAvailable(<name1> [<name2>...])
This command ensures that each of the named dependencies are made available to the project by the time it returns. There must have been a call to
FetchContent_Declare()for each dependency, and the first such call will control how that dependency will be made available, as described below.If
<lowercaseName>_SOURCE_DIRis not set:New in version 3.24: If a dependency provider is set, call the provider's command with
FETCHCONTENT_MAKEAVAILABLE_SERIALas the first argument, followed by the arguments of the first call toFetchContent_Declare()for<name>. IfSOURCE_DIRorBINARY_DIRwere not part of the original declared arguments, they will be added with their default values. IfFETCHCONTENT_TRY_FIND_PACKAGE_MODEwas set toNEVERwhen the details were declared, anyFIND_PACKAGE_ARGSwill be omitted. TheOVERRIDE_FIND_PACKAGEkeyword is also always omitted. If the provider fulfilled the request,FetchContent_MakeAvailable()will consider that dependency handled, skip the remaining steps below and move on to the next dependency in the list.New in version 3.24: If permitted,
find_package(<name> [<args>...])will be called, where<args>...may be provided by theFIND_PACKAGE_ARGSoption inFetchContent_Declare(). The value of theFETCHCONTENT_TRY_FIND_PACKAGE_MODEvariable at the timeFetchContent_Declare()was called determines whetherFetchContent_MakeAvailable()can callfind_package(). If theCMAKE_FIND_PACKAGE_TARGETS_GLOBALvariable is set to true whenFetchContent_MakeAvailable()is called, it still affects any imported targets created when that in turn callsfind_package(), even if that variable was false when the corresponding details were declared.
If the dependency was not satisfied by a provider or a
find_package()call,FetchContent_MakeAvailable()then uses the following logic to make the dependency available:If the dependency has already been populated earlier in this run, set the
<lowercaseName>_POPULATED,<lowercaseName>_SOURCE_DIRand<lowercaseName>_BINARY_DIRvariables in the same way as a call toFetchContent_GetProperties(), then skip the remaining steps below and move on to the next dependency in the list.Call
FetchContent_Populate()to populate the dependency using the details recorded by an earlier call toFetchContent_Declare(). Halt with a fatal error if no such details have been recorded.FETCHCONTENT_SOURCE_DIR_<uppercaseName>can be used to override the declared details and use content provided at the specified location instead.New in version 3.24: Ensure the
CMAKE_FIND_PACKAGE_REDIRECTS_DIRdirectory contains a<lowercaseName>-config.cmakeand a<lowercaseName>-config-version.cmakefile (or equivalently<name>Config.cmakeand<name>ConfigVersion.cmake). The directory that theCMAKE_FIND_PACKAGE_REDIRECTS_DIRvariable points to is cleared at the start of every CMake run. If no config file exists whenFetchContent_Populate()returns, a minimal one will be written whichincludesany<lowercaseName>-extra.cmakeor<name>Extra.cmakefile with theOPTIONALflag (so the files can be missing and won't generate a warning). Similarly, if no config version file exists, a very simple one will be written which setsPACKAGE_VERSION_COMPATIBLEandPACKAGE_VERSION_EXACTto true. This ensures all future calls tofind_package()for the dependency will use the redirected config file, regardless of any version requirements. CMake cannot automatically determine an arbitrary dependency's version, so it cannot setPACKAGE_VERSION. When a dependency is pulled in viaadd_subdirectory()in the next step, it may choose to overwrite the generated config version file inCMAKE_FIND_PACKAGE_REDIRECTS_DIRwith one that also setsPACKAGE_VERSION. The dependency may also write a<lowercaseName>-extra.cmakeor<name>Extra.cmakefile to perform custom processing or define any variables that their normal (installed) package config file would otherwise usually define (many projects don't do any custom processing or set any variables and therefore have no need to do this). If required, the main project can write these files instead if the dependency project doesn't do so. This allows the main project to add missing details from older dependencies that haven't or can't be updated to support this functionality. See Integrating With find_package() for examples.If the top directory of the populated content contains a
CMakeLists.txtfile, calladd_subdirectory()to add it to the main build. It is not an error for there to be noCMakeLists.txtfile, which allows the command to be used for dependencies that make downloaded content available at a known location, but which do not need or support being added directly to the build.New in version 3.18: The
SOURCE_SUBDIRoption can be given in the declared details to look somewhere below the top directory instead (i.e. the same way thatSOURCE_SUBDIRis used by theExternalProject_Add()command). The path provided withSOURCE_SUBDIRmust be relative and will be treated as relative to the top directory. It can also point to a directory that does not contain aCMakeLists.txtfile or even to a directory that doesn't exist. This can be used to avoid adding a project that contains aCMakeLists.txtfile in its top directory.New in version 3.25: If the
SYSTEMkeyword was included in the call toFetchContent_Declare(), theSYSTEMkeyword will be added to theadd_subdirectory()command as well.
Projects should aim to declare the details of all dependencies they might use before they call
FetchContent_MakeAvailable()for any of them. This ensures that if any of the dependencies are also sub-dependencies of one or more of the others, the main project still controls the details that will be used (because it will declare them first before the dependencies get a chance to). In the following code samples, assume that theuses_otherdependency also usesFetchContentto add theotherdependency internally:# WRONG: Should declare all details first FetchContent_Declare(uses_other ...) FetchContent_MakeAvailable(uses_other) FetchContent_Declare(other ...) # Will be ignored, uses_other beat us to it FetchContent_MakeAvailable(other) # Would use details declared by uses_other
# CORRECT: All details declared first, so they will take priority FetchContent_Declare(uses_other ...) FetchContent_Declare(other ...) FetchContent_MakeAvailable(uses_other other)
Note that
CMAKE_VERIFY_INTERFACE_HEADER_SETSis explicitly set to false upon entry toFetchContent_MakeAvailable(), and is restored to its original value before the command returns. Developers typically only want to verify header sets from the main project, not those from any dependencies. This local manipulation of theCMAKE_VERIFY_INTERFACE_HEADER_SETSvariable provides that intuitive behavior. You can use variables likeCMAKE_PROJECT_INCLUDEorCMAKE_PROJECT_<PROJECT-NAME>_INCLUDEto turn verification back on for all or some dependencies. You can also set theVERIFY_INTERFACE_HEADER_SETSproperty of individual targets.
- FetchContent_Populate¶
Note
Where possible, prefer to use
FetchContent_MakeAvailable()instead of implementing population manually with this command.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 toFetchContent_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 toFetchContent_Populate(). Those saved details are then used to construct a call toExternalProject_Add()in a private sub-build to perform the content population immediately. The implementation ofExternalProject_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 theFetchContent_GetProperties()command before callingFetchContent_Populate().FetchContent_Populate()will set three variables in the scope of the caller:<lowercaseName>_POPULATEDThis will always be set to
TRUEby the call.<lowercaseName>_SOURCE_DIRThe location where the populated content can be found upon return.
<lowercaseName>_BINARY_DIRA directory intended for use as a corresponding build directory.
The main use case for the
<lowercaseName>_SOURCE_DIRand<lowercaseName>_BINARY_DIRvariables is to calladd_subdirectory()immediately after population: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
FetchContent_GetProperties()command.The
FetchContent_Populate()command also supports a syntax allowing the content details to be specified directly rather than using any saved details. This is more low-level and use of this form is generally to be avoided in favor of using saved content details as outlined above. Nevertheless, in certain situations it can be useful to invoke the content population as an isolated operation (typically as part of implementing some other higher level feature or when using CMake in script mode):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_DISCONNECTEDandFETCHCONTENT_UPDATES_DISCONNECTEDcache variables are ignored.
The
<lowercaseName>_SOURCE_DIRand<lowercaseName>_BINARY_DIRvariables are still returned to the caller, but since these locations are not stored as global properties when this form is used, they are only available to the calling scope and below rather than the entire project hierarchy. No<lowercaseName>_POPULATEDvariable is set in the caller's scope with this form.The supported options for
FetchContent_Populate()are the same as those forFetchContent_Declare(). Those few options shown just above are either specific toFetchContent_Populate()or their behavior is slightly modified from howExternalProject_Add()treats them:QUIETThe
QUIEToption 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 globalFETCHCONTENT_QUIETcache variable has no effect onFetchContent_Populate()calls where the content details are provided directly.SUBBUILD_DIRThe
SUBBUILD_DIRargument can be provided to change the location of the sub-build created to perform the population. The default value is${CMAKE_CURRENT_BINARY_DIR}/<lowercaseName>-subbuildand it would be unusual to need to override this default. If a relative path is specified, it will be interpreted as relative toCMAKE_CURRENT_BINARY_DIR. This option should not be confused with theSOURCE_SUBDIRoption which only affects theFetchContent_MakeAvailable()command.SOURCE_DIR,BINARY_DIRThe
SOURCE_DIRandBINARY_DIRarguments are supported byExternalProject_Add(), but different default values are used byFetchContent_Populate().SOURCE_DIRdefaults to${CMAKE_CURRENT_BINARY_DIR}/<lowercaseName>-srcandBINARY_DIRdefaults to${CMAKE_CURRENT_BINARY_DIR}/<lowercaseName>-build. If a relative path is specified, it will be interpreted as relative toCMAKE_CURRENT_BINARY_DIR.
In addition to the above explicit options, any other unrecognized options are passed through unmodified to
ExternalProject_Add()to perform the download, patch and update steps. The following options are explicitly prohibited (they are disabled by theFetchContent_Populate()command):CONFIGURE_COMMANDBUILD_COMMANDINSTALL_COMMANDTEST_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 theCMAKE_GENERATORand/orCMAKE_MAKE_PROGRAMvariables will need to be set appropriately on the command line invoking the script.New in version 3.18: Added support for the
DOWNLOAD_NO_EXTRACToption.- FetchContent_GetProperties¶
When using saved content details, a call to
FetchContent_MakeAvailable()orFetchContent_Populate()records information in global properties which can be queried at any time. This information may include 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.FetchContent_GetProperties( <name> [SOURCE_DIR <srcDirVar>] [BINARY_DIR <binDirVar>] [POPULATED <doneVar>] )
The
SOURCE_DIR,BINARY_DIRandPOPULATEDoptions 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 toFetchContent_MakeAvailable(name)orFetchContent_Populate(name). Note that theSOURCE_DIRandBINARY_DIRvalues can be empty if the call is fulfilled by a dependency provider.This command is rarely needed when using
FetchContent_MakeAvailable(). It is more commonly used as part of implementing the following pattern withFetchContent_Populate(), which ensures that the relevant variables will always be defined regardless of whether or not the population has been performed elsewhere in the project already:# Check if population has already been performed FetchContent_GetProperties(depname) if(NOT depname_POPULATED) # Fetch the content using previously declared details FetchContent_Populate(depname) # Set custom variables, policies, etc. # ... # Bring the populated content into the build add_subdirectory(${depname_SOURCE_DIR} ${depname_BINARY_DIR}) endif()
- FetchContent_SetPopulated¶
New in version 3.24.
Note
This command should only be called by dependency providers. Calling it in any other context is unsupported and future CMake versions may halt with a fatal error in such cases.
FetchContent_SetPopulated( <name> [SOURCE_DIR <srcDir>] [BINARY_DIR <binDir>] )
If a provider command fulfills a
FETCHCONTENT_MAKEAVAILABLE_SERIALrequest, it must call this function before returning. TheSOURCE_DIRandBINARY_DIRarguments can be used to specify the values thatFetchContent_GetProperties()should return for its corresponding arguments. Only provideSOURCE_DIRandBINARY_DIRif they have the same meaning as if they had been populated by the built-inFetchContent_MakeAvailable()implementation.Variables¶
A number of cache variables can influence the behavior where details from a
FetchContent_Declare()call are used to populate content.Note
All of these variables are intended for the developer to customize behavior. They should not normally be set by the project.
- 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
FetchContentmodule to handle on the project's behalf. TheFETCHCONTENT_BASE_DIRcache 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 (
ONby 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
ONcan significantly speed up the configure stage. It isOFFby 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,FETCHCONTENT_UPDATES_DISCONNECTEDonly 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 asFETCHCONTENT_FULLY_DISCONNECTED. It isOFFby default.
- FETCHCONTENT_TRY_FIND_PACKAGE_MODE¶
New in version 3.24.
This variable modifies the details that
FetchContent_Declare()records for a given dependency. While it ultimately controls the behavior ofFetchContent_MakeAvailable(), it is the variable's value whenFetchContent_Declare()is called that gets used. It makes no difference what the variable is set to whenFetchContent_MakeAvailable()is called. Since the variable should only be set by the user and not by projects directly, it will typically have the same value throughout anyway, so this distinction is not usually noticeable.FETCHCONTENT_TRY_FIND_PACKAGE_MODEultimately controls whetherFetchContent_MakeAvailable()is allowed to callfind_package()to satisfy a dependency. The variable can be set to one of the following values:OPT_INFetchContent_MakeAvailable()will only callfind_package()if theFetchContent_Declare()call included aFIND_PACKAGE_ARGSkeyword. This is also the default behavior ifFETCHCONTENT_TRY_FIND_PACKAGE_MODEis not set.ALWAYSfind_package()can be called byFetchContent_MakeAvailable()regardless of whether theFetchContent_Declare()call included aFIND_PACKAGE_ARGSkeyword or not. If noFIND_PACKAGE_ARGSkeyword was given, the behavior will be as thoughFIND_PACKAGE_ARGShad been provided, with no additional arguments after it.NEVERFetchContent_MakeAvailable()will not callfind_package(). AnyFIND_PACKAGE_ARGSgiven to theFetchContent_Declare()call will be ignored.
As a special case, if the
FETCHCONTENT_SOURCE_DIR_<uppercaseName>variable has a non-empty value for a dependency, it is assumed that the user is overriding all other methods of making that dependency available.FETCHCONTENT_TRY_FIND_PACKAGE_MODEwill have no effect on that dependency andFetchContent_MakeAvailable()will not try to callfind_package()for it.
In addition to the above, the following variables are also defined for each content name:
- FETCHCONTENT_SOURCE_DIR_<uppercaseName>¶
If this is set, no download or update steps are performed for the specified content and the
<lowercaseName>_SOURCE_DIRvariable 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<lowercaseName>_BINARY_DIRto 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_<uppercaseName>¶
This is the per-content equivalent of
FETCHCONTENT_UPDATES_DISCONNECTED. If the global option or this option isON, 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.
Examples¶
Typical Case¶
This first fairly straightforward example ensures that some popular testing frameworks are available to the main build:
include(FetchContent) FetchContent_Declare( googletest GIT_REPOSITORY https://github.com/google/googletest.git GIT_TAG 703bd9caab50b139428cea1aaff9974ebee5742e # release-1.10.0 ) FetchContent_Declare( Catch2 GIT_REPOSITORY https://github.com/catchorg/Catch2.git GIT_TAG de6fe184a9ac1a06895cdd1c9b437f0a0bdf14ad # v2.13.4 ) # After the following call, the CMake targets defined by googletest and # Catch2 will be available to the rest of the build FetchContent_MakeAvailable(googletest Catch2)
Integrating With find_package()¶
For the previous example, if the user wanted to try to find
googletestandCatch2viafind_package()first before trying to download and build them from source, they could set theFETCHCONTENT_TRY_FIND_PACKAGE_MODEvariable toALWAYS. This would also affect any other calls toFetchContent_Declare()throughout the project, which might not be acceptable. The behavior can be enabled for just these two dependencies instead by addingFIND_PACKAGE_ARGSto the declared details and leavingFETCHCONTENT_TRY_FIND_PACKAGE_MODEunset, or set toOPT_IN:include(FetchContent) FetchContent_Declare( googletest GIT_REPOSITORY https://github.com/google/googletest.git GIT_TAG 703bd9caab50b139428cea1aaff9974ebee5742e # release-1.10.0 FIND_PACKAGE_ARGS NAMES GTest ) FetchContent_Declare( Catch2 GIT_REPOSITORY https://github.com/catchorg/Catch2.git GIT_TAG de6fe184a9ac1a06895cdd1c9b437f0a0bdf14ad # v2.13.4 FIND_PACKAGE_ARGS ) # This will try calling find_package() first for both dependencies FetchContent_MakeAvailable(googletest Catch2)
For
Catch2, no additional arguments tofind_package()are needed, so no additional arguments are provided after theFIND_PACKAGE_ARGSkeyword. Forgoogletest, its package is more commonly calledGTest, so arguments are added to support it being found by that name.If the user wanted to disable
FetchContent_MakeAvailable()from callingfind_package()for any dependency, even if it providedFIND_PACKAGE_ARGSin its declared details, they could setFETCHCONTENT_TRY_FIND_PACKAGE_MODEtoNEVER.If the project wanted to indicate that these two dependencies should be downloaded and built from source and that
find_package()calls should be redirected to use the built dependencies, theOVERRIDE_FIND_PACKAGEoption should be used when declaring the content details:include(FetchContent) FetchContent_Declare( googletest GIT_REPOSITORY https://github.com/google/googletest.git GIT_TAG 703bd9caab50b139428cea1aaff9974ebee5742e # release-1.10.0 OVERRIDE_FIND_PACKAGE ) FetchContent_Declare( Catch2 GIT_REPOSITORY https://github.com/catchorg/Catch2.git GIT_TAG de6fe184a9ac1a06895cdd1c9b437f0a0bdf14ad # v2.13.4 OVERRIDE_FIND_PACKAGE ) # The following will automatically forward through to FetchContent_MakeAvailable() find_package(googletest) find_package(Catch2)
CMake provides a FindGTest module which defines some variables that older projects may use instead of linking to the imported targets. To support those cases, we can provide an extra file. In keeping with the "first to define, wins" philosophy of
FetchContent, we only write out that file if something else hasn't already done so.FetchContent_MakeAvailable(googletest) if(NOT EXISTS ${CMAKE_FIND_PACKAGE_REDIRECTS_DIR}/googletest-extra.cmake AND NOT EXISTS ${CMAKE_FIND_PACKAGE_REDIRECTS_DIR}/googletestExtra.cmake) file(WRITE ${CMAKE_FIND_PACKAGE_REDIRECTS_DIR}/googletest-extra.cmake [=[ if("${GTEST_LIBRARIES}" STREQUAL "" AND TARGET GTest::gtest) set(GTEST_LIBRARIES GTest::gtest) endif() if("${GTEST_MAIN_LIBRARIES}" STREQUAL "" AND TARGET GTest::gtest_main) set(GTEST_MAIN_LIBRARIES GTest::gtest_main) endif() if("${GTEST_BOTH_LIBRARIES}" STREQUAL "") set(GTEST_BOTH_LIBRARIES ${GTEST_LIBRARIES} ${GTEST_MAIN_LIBRARIES}) endif() ]=]) endif()
Projects will also likely be using
find_package(GTest)rather thanfind_package(googletest), but it is possible to make use of theCMAKE_FIND_PACKAGE_REDIRECTS_DIRarea to pull in the latter as a dependency of the former. This is likely to be sufficient to satisfy a typicalfind_package(GTest)call.FetchContent_MakeAvailable(googletest) if(NOT EXISTS ${CMAKE_FIND_PACKAGE_REDIRECTS_DIR}/gtest-config.cmake AND NOT EXISTS ${CMAKE_FIND_PACKAGE_REDIRECTS_DIR}/GTestConfig.cmake) file(WRITE ${CMAKE_FIND_PACKAGE_REDIRECTS_DIR}/gtest-config.cmake [=[ include(CMakeFindDependencyMacro) find_dependency(googletest) ]=]) endif() if(NOT EXISTS ${CMAKE_FIND_PACKAGE_REDIRECTS_DIR}/gtest-config-version.cmake AND NOT EXISTS ${CMAKE_FIND_PACKAGE_REDIRECTS_DIR}/GTestConfigVersion.cmake) file(WRITE ${CMAKE_FIND_PACKAGE_REDIRECTS_DIR}/gtest-config-version.cmake [=[ include(${CMAKE_FIND_PACKAGE_REDIRECTS_DIR}/googletest-config-version.cmake OPTIONAL) if(NOT PACKAGE_VERSION_COMPATIBLE) include(${CMAKE_FIND_PACKAGE_REDIRECTS_DIR}/googletestConfigVersion.cmake OPTIONAL) endif() ]=]) endif()
Overriding Where To Find CMakeLists.txt¶
If the sub-project's
CMakeLists.txtfile is not at the top level of its source tree, theSOURCE_SUBDIRoption can be used to tellFetchContentwhere to find it. The following example shows how to use that option, and it also sets a variable which is meaningful to the subproject before pulling it into the main build (set as anINTERNALcache variable to avoid problems with policyCMP0077):include(FetchContent) FetchContent_Declare( protobuf GIT_REPOSITORY https://github.com/protocolbuffers/protobuf.git GIT_TAG ae50d9b9902526efd6c7a1907d09739f959c6297 # v3.15.0 SOURCE_SUBDIR cmake ) set(protobuf_BUILD_TESTS OFF CACHE INTERNAL "") FetchContent_MakeAvailable(protobuf)
Complex Dependency Hierarchies¶
In more complex project hierarchies, the dependency relationships can be more complicated. Consider a hierarchy where
projAis the top level project and it depends directly on projectsprojBandprojC. BothprojBandprojCcan be built standalone and they also both depend on another projectprojD.projBadditionally depends onprojE. This example assumes that all five projects are available on a company git server. TheCMakeLists.txtof each project might have sections like the following:projA:
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_Declare( projE GIT_REPOSITORY git@mycompany.com:git/projE.git GIT_TAG v2.3-rc1 ) # Order is important, see notes in the discussion further below FetchContent_MakeAvailable(projD projB projC)
projB:
include(FetchContent) FetchContent_Declare( projD GIT_REPOSITORY git@mycompany.com:git/projD.git GIT_TAG 20b415f9034bbd2a2e8216e9a5c9e632 ) FetchContent_Declare( projE GIT_REPOSITORY git@mycompany.com:git/projE.git GIT_TAG 68e20f674a48be38d60e129f600faf7d ) FetchContent_MakeAvailable(projD projE)
projC:
include(FetchContent) FetchContent_Declare( projD GIT_REPOSITORY git@mycompany.com:git/projD.git GIT_TAG 7d9a17ad2c962aa13e2fbb8043fb6b8a ) # This particular version of projD requires workarounds FetchContent_GetProperties(projD) if(NOT projd_POPULATED) FetchContent_Populate(projD) # Copy an additional/replacement file into the populated source file(COPY someFile.c DESTINATION ${projd_SOURCE_DIR}/src) add_subdirectory(${projd_SOURCE_DIR} ${projd_BINARY_DIR}) endif()
A few key points should be noted in the above:
projBandprojCdefine different content details forprojD, butprojAalso defines a set of content details forprojD. BecauseprojAwill define them first, the details fromprojBandprojCwill not be used. The override details defined byprojAare not required to match either of those fromprojBorprojC, but it is up to the higher level project to ensure that the details it does define still make sense for the child projects.In the
projAcall toFetchContent_MakeAvailable(),projDis listed ahead ofprojBandprojCto ensure thatprojAis in control of howprojDis populated.While
projAdefines content details forprojE, it does not need to explicitly callFetchContent_MakeAvailable(projE)orFetchContent_Populate(projD)itself. Instead, it leaves that to the childprojB. For higher level projects, it is often enough to just define the override content details and leave the actual population to the child projects. This saves repeating the same thing at each level of the project hierarchy unnecessarily.
Populating Content Without Adding It To The Build¶
Projects don't always need to add the populated content to the build. Sometimes the project just wants to make the downloaded content available at a predictable location. The next example ensures that a set of standard company toolchain files (and potentially even the toolchain binaries themselves) is available early enough to be used for that same build.
cmake_minimum_required(VERSION 3.14) include(FetchContent) FetchContent_Declare( mycom_toolchains URL https://intranet.mycompany.com//toolchains_1.3.2.tar.gz ) FetchContent_MakeAvailable(mycom_toolchains) project(CrossCompileExample)
The project could be configured to use one of the downloaded toolchains like so:
cmake -DCMAKE_TOOLCHAIN_FILE=_deps/mycom_toolchains-src/toolchain_arm.cmake /path/to/srcWhen CMake processes the
CMakeLists.txtfile, it will download and unpack the tarball into_deps/mycompany_toolchains-srcrelative to the build directory. TheCMAKE_TOOLCHAIN_FILEvariable is not used until theproject()command is reached, at which point CMake looks for the named toolchain file relative to the build directory. Because the tarball has already been downloaded and unpacked by then, the toolchain file will be in place, even the very first time thatcmakeis run in the build directory.Populating Content In CMake Script Mode¶
This last example demonstrates how one might download and unpack a firmware tarball using CMake's
script mode. The call toFetchContent_Populate()specifies all the content details and the unpacked firmware will be placed in afirmwaredirectory below the current working directory.getFirmware.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 )