code:
<!DOCTYPE html>

    <meta charset="utf-8" />
    <meta name="viewport" content="width=device-width, initial-scale=1.0" /><meta name="generator" content="Docutils 0.19: https://docutils.sourceforge.io/" />

  <title>FetchContent — CMake 3.29.0-rc3 Documentation</title>

    <link rel="stylesheet" type="text/css" href="../_static/pygments.css" />
    <link rel="stylesheet" type="text/css" href="../_static/cmake.css" />

    <link rel="icon" href="../_static/cmake-favicon.ico"/>
    <link rel="index" title="Index" href="../genindex.html" />
    <link rel="search" title="Search" href="../search.html" />
    <link rel="next" title="FindPackageHandleStandardArgs" href="FindPackageHandleStandardArgs.html" />
    <link rel="prev" title="FeatureSummary" href="FeatureSummary.html" />

Navigation

          index

          next |

          previous |

    CMake »

    3.29.0-rc3 Documentation »

cmake-modules(7) »

FetchContent

FetchContent¶

New in version 3.11.

Contents

FetchContent

Overview

Commands

Variables

Examples

Typical Case

Integrating With find_package()

Overriding Where To Find CMakeLists.txt

Complex Dependency Hierarchies

Populating Content Without Adding It To The Build

Populating Content In CMake Script Mode

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>...
  [EXCLUDE_FROM_ALL]
  [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 level 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, update or patch options
that the ExternalProject_Add() command understands.  The configure,
build, install and test steps are explicitly disabled and therefore options
related to them will be ignored.  The SOURCE_SUBDIR option is an
exception, see FetchContent_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_TAG rather
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_NETRC and CMAKE_NETRC_FILE variables now
provide the defaults for their corresponding content options, just like
they do for ExternalProject_Add(). Previously, these variables
were ignored by the FetchContent module.

New in version 3.24:

FIND_PACKAGE_ARGS

This option is for scenarios where the
FetchContent_MakeAvailable() command may first try a call to
find_package() to satisfy the dependency for <name>.
By default, such a call would be simply find_package(<name>), but
FIND_PACKAGE_ARGS can be used to provide additional arguments to be
appended after the <name>.  FIND_PACKAGE_ARGS can also be given
with nothing after it, which indicates that find_package() can
still be called if FETCHCONTENT_TRY_FIND_PACKAGE_MODE is
set to OPT_IN or is not set.

It would not normally be appropriate to specify REQUIRED as one of
the additional arguments after FIND_PACKAGE_ARGS.  Doing so would
mean the find_package() call must succeed, so none of the other
details specified in the FetchContent_Declare() call would get a
chance to be used as a fall-back.

Everything after the FIND_PACKAGE_ARGS keyword is appended to the
find_package() call, so all other <contentOptions> must
come before the FIND_PACKAGE_ARGS keyword.  If the
CMAKE_FIND_PACKAGE_TARGETS_GLOBAL variable is set to true
at the time FetchContent_Declare() is called, a GLOBAL keyword
will be appended to the find_package() arguments if it was
not already specified.  It will also be appended if
FIND_PACKAGE_ARGS was not given, but
FETCHCONTENT_TRY_FIND_PACKAGE_MODE was set to ALWAYS.

OVERRIDE_FIND_PACKAGE cannot be used when FIND_PACKAGE_ARGS is
given.

Dependency Providers discusses another way that
FetchContent_MakeAvailable() calls can be redirected.
FIND_PACKAGE_ARGS is intended for project control, whereas
dependency providers allow users to override project behavior.

OVERRIDE_FIND_PACKAGE

When a FetchContent_Declare(<name> ...) call includes this option,
subsequent calls to find_package(<name> ...) will ensure that
FetchContent_MakeAvailable(<name>) has been called, then use the
config package files in the CMAKE_FIND_PACKAGE_REDIRECTS_DIR
directory (which are usually created by FetchContent_MakeAvailable()).
This effectively makes FetchContent_MakeAvailable() override
find_package() for the named dependency, allowing the former to
satisfy the package requirements of the latter.  FIND_PACKAGE_ARGS
cannot be used when OVERRIDE_FIND_PACKAGE is given.

If a dependency provider has been set
and the project calls find_package() for the <name>
dependency, OVERRIDE_FIND_PACKAGE will not prevent the provider
from seeing that call.  Dependency providers always have the opportunity
to intercept any direct call to find_package(), except if that
call contains the BYPASS_PROVIDER option.

New in version 3.25:

SYSTEM

If the SYSTEM argument is provided, the SYSTEM directory
property of a subdirectory added by
FetchContent_MakeAvailable() will be set to true.  This will
affect non-imported targets created as part of that command.
See the SYSTEM target property documentation for a more
detailed discussion of the effects.

New in version 3.28:

EXCLUDE_FROM_ALL

If the EXCLUDE_FROM_ALL argument is provided, then targets in the
subdirectory added by FetchContent_MakeAvailable() will not be
included in the ALL target by default, and may be excluded from IDE
project files. See the add_subdirectory() EXCLUDE_FROM_ALL
argument 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_DIR is not set:

New in version 3.24: If a dependency provider is set, call the
provider's command with FETCHCONTENT_MAKEAVAILABLE_SERIAL as the
first argument, followed by the arguments of the first call to
FetchContent_Declare() for <name>.  If SOURCE_DIR or
BINARY_DIR were not part of the original declared arguments, they
will be added with their default values.
If FETCHCONTENT_TRY_FIND_PACKAGE_MODE was set to NEVER
when the details were declared, any FIND_PACKAGE_ARGS will be
omitted.  The OVERRIDE_FIND_PACKAGE keyword 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 the
FIND_PACKAGE_ARGS option in FetchContent_Declare().
The value of the FETCHCONTENT_TRY_FIND_PACKAGE_MODE variable
at the time FetchContent_Declare() was called determines whether
FetchContent_MakeAvailable() can call find_package().
If the CMAKE_FIND_PACKAGE_TARGETS_GLOBAL variable is set to
true when FetchContent_MakeAvailable() is called, it still affects
any imported targets created when that in turn calls
find_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_DIR and
<lowercaseName>_BINARY_DIR variables in the same way as a call to
FetchContent_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 to FetchContent_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_DIR directory
contains a <lowercaseName>-config.cmake and a
<lowercaseName>-config-version.cmake file (or equivalently
<name>Config.cmake and <name>ConfigVersion.cmake).
The directory that the CMAKE_FIND_PACKAGE_REDIRECTS_DIR
variable points to is cleared at the start of every CMake run.
If no config file exists when FetchContent_Populate() returns,
a minimal one will be written which includes any
<lowercaseName>-extra.cmake or <name>Extra.cmake file with the
OPTIONAL flag (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 sets PACKAGE_VERSION_COMPATIBLE and
PACKAGE_VERSION_EXACT to true.  This ensures all future calls to
find_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 set PACKAGE_VERSION.
When a dependency is pulled in via add_subdirectory() in the
next step, it may choose to overwrite the generated config version file
in CMAKE_FIND_PACKAGE_REDIRECTS_DIR with one that also sets
PACKAGE_VERSION.
The dependency may also write a <lowercaseName>-extra.cmake or
<name>Extra.cmake file 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.txt
file, call add_subdirectory() to add it to the main build.
It is not an error for there to be no CMakeLists.txt file, 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_SUBDIR option can be given in the declared details to
look somewhere below the top directory instead (i.e. the same way that
SOURCE_SUBDIR is used by the ExternalProject_Add()
command).  The path provided with SOURCE_SUBDIR must be relative
and will be treated as relative to the top directory.  It can also
point to a directory that does not contain a CMakeLists.txt file
or even to a directory that doesn't exist.  This can be used to avoid
adding a project that contains a CMakeLists.txt file in its top
directory.

New in version 3.25: If the SYSTEM keyword was included in the call to
FetchContent_Declare(), the SYSTEM keyword will be
added to the add_subdirectory() command as well.

New in version 3.28: If the EXCLUDE_FROM_ALL keyword was included in the call to
FetchContent_Declare(), the EXCLUDE_FROM_ALL keyword will
be added to the add_subdirectory() command as well.

New in version 3.29: CMAKE_EXPORT_FIND_PACKAGE_NAME is set to the dependency name
before calling add_subdirectory().

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
the uses_other dependency also uses FetchContent to add the other
dependency 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_SETS is explicitly set
to false upon entry to FetchContent_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 the
CMAKE_VERIFY_INTERFACE_HEADER_SETS variable provides that
intuitive behavior.  You can use variables like
CMAKE_PROJECT_INCLUDE or
CMAKE_PROJECT_<PROJECT-NAME>_INCLUDE to turn verification back
on for all or some dependencies.  You can also set the
VERIFY_INTERFACE_HEADER_SETS property 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 to 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 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
FetchContent_GetProperties() command before calling
FetchContent_Populate().

FetchContent_Populate() will set three variables in the scope of the
caller:

<lowercaseName>_POPULATED

This will always be set to TRUE by the call.

<lowercaseName>_SOURCE_DIR

The location where the populated content can be found upon return.

<lowercaseName>_BINARY_DIR

A directory intended for use as a corresponding build directory.

The main use case for the <lowercaseName>_SOURCE_DIR and
<lowercaseName>_BINARY_DIR variables is to call
add_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_DISCONNECTED and
FETCHCONTENT_UPDATES_DISCONNECTED cache variables are ignored.

The <lowercaseName>_SOURCE_DIR and <lowercaseName>_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 <lowercaseName>_POPULATED variable is set in the caller's
scope with this form.

The supported options for FetchContent_Populate() are the same as those
for FetchContent_Declare().  Those few options shown just
above are either specific to FetchContent_Populate() or their behavior is
slightly modified from how 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}/<lowercaseName>-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 CMAKE_CURRENT_BINARY_DIR.
This option should not be confused with the SOURCE_SUBDIR option which
only affects the FetchContent_MakeAvailable() command.

SOURCE_DIR, BINARY_DIR

The SOURCE_DIR and BINARY_DIR arguments are supported by
ExternalProject_Add(), but different default values are used by
FetchContent_Populate().  SOURCE_DIR defaults to
${CMAKE_CURRENT_BINARY_DIR}/<lowercaseName>-src and BINARY_DIR
defaults to ${CMAKE_CURRENT_BINARY_DIR}/<lowercaseName>-build.
If a relative path is specified, it will be interpreted as relative to
CMAKE_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 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 CMAKE_GENERATOR and/or
CMAKE_MAKE_PROGRAM variables will need to be set appropriately
on the command line invoking the script.

New in version 3.18: Added support for the DOWNLOAD_NO_EXTRACT option.

FetchContent_GetProperties¶

When using saved content details, a call to
FetchContent_MakeAvailable() or FetchContent_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_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
FetchContent_MakeAvailable(name) or
FetchContent_Populate(name).
Note that the SOURCE_DIR and BINARY_DIR values 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 with FetchContent_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_SERIAL
request, it must call this function before returning.  The SOURCE_DIR
and BINARY_DIR arguments can be used to specify the values that
FetchContent_GetProperties() should return for its corresponding
arguments.  Only provide SOURCE_DIR and BINARY_DIR if they have
the same meaning as if they had been populated by the built-in
FetchContent_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 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.

Note

The FETCHCONTENT_FULLY_DISCONNECTED variable is not an appropriate way
to prevent any network access on the first run in a build directory.
Doing so can break projects, lead to misleading error messages, and hide
subtle population failures.  This variable is specifically intended to
only be turned on after the first time CMake has been run.
If you want to prevent network access even on the first run, use a
dependency provider and populate the
dependency from local content instead.

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_DISCONNECTED only
prevents the update step from making connections to remote servers
when using the git or hg download methods.  Updates still occur if details
about the update step change, but the update is attempted with only the
information already available locally (so switching to a different tag or
commit that is already fetched locally will succeed, but switching to an
unknown commit hash will fail).  The download step is not affected, so if
content has not been downloaded previously, it will still be downloaded
when this option is enabled.  This can speed up the configure step, but
not as much as FETCHCONTENT_FULLY_DISCONNECTED.
FETCHCONTENT_UPDATES_DISCONNECTED is OFF by 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
of FetchContent_MakeAvailable(), it is the variable's value when
FetchContent_Declare() is called that gets used.  It makes no
difference what the variable is set to when
FetchContent_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_MODE ultimately controls whether
FetchContent_MakeAvailable() is allowed to call
find_package() to satisfy a dependency.  The variable can be set
to one of the following values:

OPT_IN

FetchContent_MakeAvailable() will only call
find_package() if the FetchContent_Declare() call
included a FIND_PACKAGE_ARGS keyword.  This is also the default
behavior if FETCHCONTENT_TRY_FIND_PACKAGE_MODE is not set.

ALWAYS

find_package() can be called by
FetchContent_MakeAvailable() regardless of whether the
FetchContent_Declare() call included a FIND_PACKAGE_ARGS
keyword or not.  If no FIND_PACKAGE_ARGS keyword was given, the
behavior will be as though FIND_PACKAGE_ARGS had been provided,
with no additional arguments after it.

NEVER

FetchContent_MakeAvailable() will not call
find_package().  Any FIND_PACKAGE_ARGS given to the
FetchContent_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_MODE will have no effect on that
dependency and FetchContent_MakeAvailable() will not try to call
find_package() for it.

In addition to the above, the following variables are also defined for each
content name:

FETCHCONTENT_SOURCE_DIR_<uppercaseName><a class="headerlink" href="#variable:FETCHCONTENT_SOURCE_DIR_<uppercaseName>" title="Permalink to this definition">¶

If this is set, no download or update steps are performed for the specified
content and the <lowercaseName>_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 <lowercaseName>_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_<uppercaseName><a class="headerlink" href="#variable:FETCHCONTENT_UPDATES_DISCONNECTED_<uppercaseName>" title="Permalink to this definition">¶

This is the per-content equivalent of
FETCHCONTENT_UPDATES_DISCONNECTED.  If the global option or
this option is ON, then updates for the git and hg methods will not
contact any remote for the named content.  They will only use information
already available locally.  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        605a34765aa5d5ecbf476b4598a862ada971b0cc # v3.0.1
)

# 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 googletest
and Catch2 via find_package() first before trying to download
and build them from source, they could set the
FETCHCONTENT_TRY_FIND_PACKAGE_MODE variable to ALWAYS.
This would also affect any other calls to FetchContent_Declare()
throughout the project, which might not be acceptable.  The behavior can be
enabled for just these two dependencies instead by adding FIND_PACKAGE_ARGS
to the declared details and leaving
FETCHCONTENT_TRY_FIND_PACKAGE_MODE unset, or set to OPT_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        605a34765aa5d5ecbf476b4598a862ada971b0cc # v3.0.1
  FIND_PACKAGE_ARGS
)

# This will try calling find_package() first for both dependencies
FetchContent_MakeAvailable(googletest Catch2)

For Catch2, no additional arguments to find_package() are needed,
so no additional arguments are provided after the FIND_PACKAGE_ARGS
keyword.  For googletest, its package is more commonly called GTest,
so arguments are added to support it being found by that name.

If the user wanted to disable FetchContent_MakeAvailable() from
calling find_package() for any dependency, even if it provided
FIND_PACKAGE_ARGS in its declared details, they could set
FETCHCONTENT_TRY_FIND_PACKAGE_MODE to NEVER.

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, the
OVERRIDE_FIND_PACKAGE option 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        605a34765aa5d5ecbf476b4598a862ada971b0cc # v3.0.1
  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 than
find_package(googletest), but it is possible to make use of the
CMAKE_FIND_PACKAGE_REDIRECTS_DIR area to pull in the latter as
a dependency of the former.  This is likely to be sufficient to satisfy
a typical find_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.txt file is not at the top level of its
source tree, the SOURCE_SUBDIR option can be used to tell FetchContent
where 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 an INTERNAL cache variable to avoid
problems with policy CMP0077):

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 projA is the top level project and
it depends directly on projects projB and projC.  Both projB and
projC can be built standalone and they also both depend on another project
projD.  projB additionally depends on projE.  This example assumes
that all five projects are available on a company git server.  The
CMakeLists.txt of 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:

projB and projC define different content details for projD,
but projA also defines a set of content details for projD.
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.

In the projA call to FetchContent_MakeAvailable(), projD
is listed ahead of projB and projC to ensure that projA is in
control of how projD is populated.

While projA defines content details for projE, it does not need
to explicitly call FetchContent_MakeAvailable(projE) or
FetchContent_Populate(projD) itself.  Instead, it leaves that to the
child projB.  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/src

When CMake processes the CMakeLists.txt file, it will download and unpack
the tarball into _deps/mycompany_toolchains-src relative to the build
directory.  The CMAKE_TOOLCHAIN_FILE variable is not used until
the project() 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 that cmake is 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 to
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¶

# 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
)

Table of Contents

FetchContent

Overview

Commands

Variables

Examples

Typical Case

Integrating With find_package()

Overriding Where To Find CMakeLists.txt

Complex Dependency Hierarchies

Populating Content Without Adding It To The Build

Populating Content In CMake Script Mode

Previous topic

FeatureSummary

Next topic

FindPackageHandleStandardArgs

This Page

Show Source

Quick search

    <form class="search" action="../search.html" method="get">
      <input type="text" name="q" aria-labelledby="searchlabel" autocomplete="off" autocorrect="off" autocapitalize="off" spellcheck="false"/>
      <input type="submit" value="Go" />
    </form>

Navigation

          index

          next |

          previous |

    CMake »

    3.29.0-rc3 Documentation »

cmake-modules(7) »

FetchContent

        © Copyright 2000-2024 Kitware, Inc. and Contributors.
      Created using Sphinx 6.2.1.


code:
<!DOCTYPE html>

    <meta charset="utf-8" />
    <meta name="viewport" content="width=device-width, initial-scale=1.0" /><meta name="generator" content="Docutils 0.19: https://docutils.sourceforge.io/" />

  <title>FindALSA — CMake 3.29.0-rc3 Documentation</title>

    <link rel="stylesheet" type="text/css" href="../_static/pygments.css" />
    <link rel="stylesheet" type="text/css" href="../_static/cmake.css" />

    <link rel="icon" href="../_static/cmake-favicon.ico"/>
    <link rel="index" title="Index" href="../genindex.html" />
    <link rel="search" title="Search" href="../search.html" />
    <link rel="next" title="FindArmadillo" href="FindArmadillo.html" />
    <link rel="prev" title="UsewxWidgets" href="UsewxWidgets.html" />

Navigation

          index

          next |

          previous |

    CMake »

    3.29.0-rc3 Documentation »

cmake-modules(7) »

FindALSA

FindALSA¶

Find Advanced Linux Sound Architecture (ALSA)

Find the alsa libraries (asound)

IMPORTED Targets¶

New in version 3.12.

This module defines IMPORTED target ALSA::ALSA, if
ALSA has been found.

Result Variables¶

This module defines the following variables:

ALSA_FOUND

True if ALSA_INCLUDE_DIR & ALSA_LIBRARY are found

ALSA_LIBRARIES

List of libraries when using ALSA.

ALSA_INCLUDE_DIRS

Where to find the ALSA headers.

Cache variables¶

The following cache variables may also be set:

ALSA_INCLUDE_DIR

the ALSA include directory

ALSA_LIBRARY

the absolute path of the asound library

Table of Contents

FindALSA

IMPORTED Targets

Result Variables

Cache variables

Previous topic

UsewxWidgets

Next topic

FindArmadillo

This Page

Show Source

Quick search

    <form class="search" action="../search.html" method="get">
      <input type="text" name="q" aria-labelledby="searchlabel" autocomplete="off" autocorrect="off" autocapitalize="off" spellcheck="false"/>
      <input type="submit" value="Go" />
    </form>

Navigation

          index

          next |

          previous |

    CMake »

    3.29.0-rc3 Documentation »

cmake-modules(7) »

FindALSA

        © Copyright 2000-2024 Kitware, Inc. and Contributors.
      Created using Sphinx 6.2.1.

repo_name: lazytadpole/codenamesilverfish

license: mit


code:
<!DOCTYPE html>

    <meta charset="utf-8" />
    <meta name="viewport" content="width=device-width, initial-scale=1.0" /><meta name="generator" content="Docutils 0.19: https://docutils.sourceforge.io/" />

  <title>FindASPELL — CMake 3.29.0-rc3 Documentation</title>

    <link rel="stylesheet" type="text/css" href="../_static/pygments.css" />
    <link rel="stylesheet" type="text/css" href="../_static/cmake.css" />

    <link rel="icon" href="../_static/cmake-favicon.ico"/>
    <link rel="index" title="Index" href="../genindex.html" />
    <link rel="search" title="Search" href="../search.html" />
    <link rel="next" title="FindAVIFile" href="FindAVIFile.html" />
    <link rel="prev" title="FindArmadillo" href="FindArmadillo.html" />

Navigation

          index

          next |

          previous |

    CMake »

    3.29.0-rc3 Documentation »

cmake-modules(7) »

FindASPELL

FindASPELL¶

Try to find ASPELL

Once done this will define

ASPELL_FOUND - system has ASPELL
ASPELL_EXECUTABLE - the ASPELL executable
ASPELL_INCLUDE_DIR - the ASPELL include directory
ASPELL_LIBRARIES - The libraries needed to use ASPELL
ASPELL_DEFINITIONS - Compiler switches required for using ASPELL

Previous topic

FindArmadillo

Next topic

FindAVIFile

This Page

Show Source

Quick search

    <form class="search" action="../search.html" method="get">
      <input type="text" name="q" aria-labelledby="searchlabel" autocomplete="off" autocorrect="off" autocapitalize="off" spellcheck="false"/>
      <input type="submit" value="Go" />
    </form>

Navigation

          index

          next |

          previous |

    CMake »

    3.29.0-rc3 Documentation »

cmake-modules(7) »

FindASPELL

        © Copyright 2000-2024 Kitware, Inc. and Contributors.
      Created using Sphinx 6.2.1.


code:
<!DOCTYPE html>

    <meta charset="utf-8" />
    <meta name="viewport" content="width=device-width, initial-scale=1.0" /><meta name="generator" content="Docutils 0.19: https://docutils.sourceforge.io/" />

  <title>FindAVIFile — CMake 3.29.0-rc3 Documentation</title>

    <link rel="stylesheet" type="text/css" href="../_static/pygments.css" />
    <link rel="stylesheet" type="text/css" href="../_static/cmake.css" />

    <link rel="icon" href="../_static/cmake-favicon.ico"/>
    <link rel="index" title="Index" href="../genindex.html" />
    <link rel="search" title="Search" href="../search.html" />
    <link rel="next" title="FindBacktrace" href="FindBacktrace.html" />
    <link rel="prev" title="FindASPELL" href="FindASPELL.html" />

Navigation

          index

          next |

          previous |

    CMake »

    3.29.0-rc3 Documentation »

cmake-modules(7) »

FindAVIFile

FindAVIFile¶

Locate AVIFILE library and include paths

AVIFILE (https://avifile.sourceforge.net/) is a set of libraries for
i386 machines to use various AVI codecs.  Support is limited beyond
Linux.  Windows provides native AVI support, and so doesn't need this
library.  This module defines

AVIFILE_INCLUDE_DIR, where to find avifile.h , etc.
AVIFILE_LIBRARIES, the libraries to link against
AVIFILE_DEFINITIONS, definitions to use when compiling
AVIFILE_FOUND, If false, don't try to use AVIFILE

Previous topic

FindASPELL

Next topic

FindBacktrace

This Page

Show Source

Quick search

    <form class="search" action="../search.html" method="get">
      <input type="text" name="q" aria-labelledby="searchlabel" autocomplete="off" autocorrect="off" autocapitalize="off" spellcheck="false"/>
      <input type="submit" value="Go" />
    </form>

Navigation

          index

          next |

          previous |

    CMake »

    3.29.0-rc3 Documentation »

cmake-modules(7) »

FindAVIFile

        © Copyright 2000-2024 Kitware, Inc. and Contributors.
      Created using Sphinx 6.2.1.


code:
<!DOCTYPE html>

    <meta charset="utf-8" />
    <meta name="viewport" content="width=device-width, initial-scale=1.0" /><meta name="generator" content="Docutils 0.19: https://docutils.sourceforge.io/" />

  <title>FindArmadillo — CMake 3.29.0-rc3 Documentation</title>

    <link rel="stylesheet" type="text/css" href="../_static/pygments.css" />
    <link rel="stylesheet" type="text/css" href="../_static/cmake.css" />

    <link rel="icon" href="../_static/cmake-favicon.ico"/>
    <link rel="index" title="Index" href="../genindex.html" />
    <link rel="search" title="Search" href="../search.html" />
    <link rel="next" title="FindASPELL" href="FindASPELL.html" />
    <link rel="prev" title="FindALSA" href="FindALSA.html" />

Navigation

          index

          next |

          previous |

    CMake »

    3.29.0-rc3 Documentation »

cmake-modules(7) »

FindArmadillo

FindArmadillo¶

Find the Armadillo C++ library.
Armadillo is a library for linear algebra & scientific computing.

New in version 3.18: Support for linking wrapped libraries directly (ARMA_DONT_USE_WRAPPER).

Using Armadillo:

find_package(Armadillo REQUIRED)
include_directories(${ARMADILLO_INCLUDE_DIRS})
add_executable(foo foo.cc)
target_link_libraries(foo ${ARMADILLO_LIBRARIES})

This module sets the following variables:

ARMADILLO_FOUND - set to true if the library is found
ARMADILLO_INCLUDE_DIRS - list of required include directories
ARMADILLO_LIBRARIES - list of libraries to be linked
ARMADILLO_VERSION_MAJOR - major version number
ARMADILLO_VERSION_MINOR - minor version number
ARMADILLO_VERSION_PATCH - patch version number
ARMADILLO_VERSION_STRING - version number as a string (ex: "1.0.4")
ARMADILLO_VERSION_NAME - name of the version (ex: "Antipodean Antileech")

Previous topic

FindALSA

Next topic

FindASPELL

This Page

Show Source

Quick search

    <form class="search" action="../search.html" method="get">
      <input type="text" name="q" aria-labelledby="searchlabel" autocomplete="off" autocorrect="off" autocapitalize="off" spellcheck="false"/>
      <input type="submit" value="Go" />
    </form>

Navigation

          index

          next |

          previous |

    CMake »

    3.29.0-rc3 Documentation »

cmake-modules(7) »

FindArmadillo

        © Copyright 2000-2024 Kitware, Inc. and Contributors.
      Created using Sphinx 6.2.1.


code:
<!DOCTYPE html>

    <meta charset="utf-8" />
    <meta name="viewport" content="width=device-width, initial-scale=1.0" /><meta name="generator" content="Docutils 0.19: https://docutils.sourceforge.io/" />

  <title>FindBISON — CMake 3.29.0-rc3 Documentation</title>

    <link rel="stylesheet" type="text/css" href="../_static/pygments.css" />
    <link rel="stylesheet" type="text/css" href="../_static/cmake.css" />

    <link rel="icon" href="../_static/cmake-favicon.ico"/>
    <link rel="index" title="Index" href="../genindex.html" />
    <link rel="search" title="Search" href="../search.html" />
    <link rel="next" title="FindBLAS" href="FindBLAS.html" />
    <link rel="prev" title="FindBacktrace" href="FindBacktrace.html" />

Navigation

          index

          next |

          previous |

    CMake »

    3.29.0-rc3 Documentation »

cmake-modules(7) »

FindBISON

FindBISON¶

Find bison executable and provide a macro to generate custom build rules.

The module defines the following variables:

BISON_EXECUTABLE

path to the bison program

BISON_VERSION

version of bison

BISON_FOUND

"True" if the program was found

The minimum required version of bison can be specified using the
standard CMake syntax, e.g.  find_package(BISON 2.1.3).

If bison is found, the module defines the macro:

BISON_TARGET(<Name> <YaccInput> <CodeOutput>
             [COMPILE_FLAGS <flags>]
             [DEFINES_FILE <file>]
             [VERBOSE [<file>]]
             [REPORT_FILE <file>]
             )

which will create a custom rule to generate a parser.  <YaccInput> is
the path to a yacc file.  <CodeOutput> is the name of the source file
generated by bison.  A header file is also be generated, and contains
the token list.

Changed in version 3.14: When CMP0088 is set to NEW, bison runs in the
CMAKE_CURRENT_BINARY_DIR directory.

The options are:

COMPILE_FLAGS <flags>

Specify flags to be added to the bison command line.

DEFINES_FILE <file>

New in version 3.4.

Specify a non-default header <file> to be generated by bison.

VERBOSE [<file>]

Tell bison to write a report file of the grammar and parser.

Deprecated since version 3.7: If <file> is given, it specifies path the report file is copied to.
[<file>] is left for backward compatibility of this module.
Use VERBOSE REPORT_FILE <file>.

REPORT_FILE <file>

New in version 3.7.

Specify a non-default report <file>, if generated.

The macro defines the following variables:

BISON_<Name>_DEFINED

True is the macro ran successfully

BISON_<Name>_INPUT

The input source file, an alias for <YaccInput>

BISON_<Name>_OUTPUT_SOURCE

The source file generated by bison

BISON_<Name>_OUTPUT_HEADER

The header file generated by bison

BISON_<Name>_OUTPUTS

All files generated by bison including the source, the header and the report

BISON_<Name>_COMPILE_FLAGS

Options used in the bison command line

Example usage:

find_package(BISON)
BISON_TARGET(MyParser parser.y ${CMAKE_CURRENT_BINARY_DIR}/parser.cpp
             DEFINES_FILE ${CMAKE_CURRENT_BINARY_DIR}/parser.h)
add_executable(Foo main.cpp ${BISON_MyParser_OUTPUTS})

Previous topic

FindBacktrace

Next topic

FindBLAS

This Page

Show Source

Quick search

    <form class="search" action="../search.html" method="get">
      <input type="text" name="q" aria-labelledby="searchlabel" autocomplete="off" autocorrect="off" autocapitalize="off" spellcheck="false"/>
      <input type="submit" value="Go" />
    </form>

Navigation

          index

          next |

          previous |

    CMake »

    3.29.0-rc3 Documentation »

cmake-modules(7) »

FindBISON

        © Copyright 2000-2024 Kitware, Inc. and Contributors.
      Created using Sphinx 6.2.1.


code:
<!DOCTYPE html>

    <meta charset="utf-8" />
    <meta name="viewport" content="width=device-width, initial-scale=1.0" /><meta name="generator" content="Docutils 0.19: https://docutils.sourceforge.io/" />

  <title>FindBLAS — CMake 3.29.0-rc3 Documentation</title>

    <link rel="stylesheet" type="text/css" href="../_static/pygments.css" />
    <link rel="stylesheet" type="text/css" href="../_static/cmake.css" />

    <link rel="icon" href="../_static/cmake-favicon.ico"/>
    <link rel="index" title="Index" href="../genindex.html" />
    <link rel="search" title="Search" href="../search.html" />
    <link rel="next" title="FindBoost" href="FindBoost.html" />
    <link rel="prev" title="FindBISON" href="FindBISON.html" />

Navigation

          index

          next |

          previous |

    CMake »

    3.29.0-rc3 Documentation »

cmake-modules(7) »

FindBLAS

FindBLAS¶

Find Basic Linear Algebra Subprograms (BLAS) library

This module finds an installed Fortran library that implements the
BLAS linear-algebra interface.

At least one of the C, CXX, or Fortran languages must be enabled.

Input Variables¶

The following variables may be set to influence this module's behavior:

BLA_STATIC

if ON use static linkage

BLA_VENDOR

Set to one of the BLAS/LAPACK Vendors to search for BLAS only
from the specified vendor.  If not set, all vendors are considered.

BLA_F95

if ON tries to find the BLAS95 interfaces

BLA_PREFER_PKGCONFIG

New in version 3.11.

if set pkg-config will be used to search for a BLAS library first
and if one is found that is preferred

BLA_PKGCONFIG_BLAS

New in version 3.25.

If set, the pkg-config method will look for this module name instead of
just blas.

BLA_SIZEOF_INTEGER

New in version 3.22.

Specify the BLAS/LAPACK library integer size:

4

Search for a BLAS/LAPACK with 32-bit integer interfaces.

8

Search for a BLAS/LAPACK with 64-bit integer interfaces.

ANY

Search for any BLAS/LAPACK.
Most likely, a BLAS/LAPACK with 32-bit integer interfaces will be found.

Imported targets¶

This module defines the following IMPORTED targets:

BLAS::BLAS

New in version 3.18.

The libraries to use for BLAS, if found.

Result Variables¶

This module defines the following variables:

BLAS_FOUND

library implementing the BLAS interface is found

BLAS_LINKER_FLAGS

uncached list of required linker flags (excluding -l and -L).

BLAS_LIBRARIES

uncached list of libraries (using full path name) to link against
to use BLAS (may be empty if compiler implicitly links BLAS)

BLAS95_LIBRARIES

uncached list of libraries (using full path name) to link against
to use BLAS95 interface

BLAS95_FOUND

library implementing the BLAS95 interface is found

BLAS/LAPACK Vendors¶

Generic

Generic reference implementation

ACML, ACML_MP, ACML_GPU

AMD Core Math Library

AOCL, AOCL_mt

New in version 3.27.

AMD Optimizing CPU Libraries

Apple, NAS

Apple BLAS (Accelerate), and Apple NAS (vecLib)

Arm, Arm_mp, Arm_ilp64, Arm_ilp64_mp

New in version 3.18.

Arm Performance Libraries

ATLAS

Automatically Tuned Linear Algebra Software

CXML, DXML

Compaq/Digital Extended Math Library

EML, EML_mt

New in version 3.20.

Elbrus Math Library

FLAME

New in version 3.11.

BLIS Framework

FlexiBLAS

New in version 3.19.

Fujitsu_SSL2, Fujitsu_SSL2BLAMP, Fujitsu_SSL2SVE, Fujitsu_SSL2BLAMPSVE

New in version 3.20.

Fujitsu SSL2 serial and parallel blas/lapack with SVE instructions

Goto

GotoBLAS

IBMESSL, IBMESSL_SMP

IBM Engineering and Scientific Subroutine Library

Intel

Intel MKL 32 bit and 64 bit obsolete versions

Intel10_32

Intel MKL v10 32 bit, threaded code

Intel10_64lp

Intel MKL v10+ 64 bit, threaded code, lp64 model

Intel10_64lp_seq

Intel MKL v10+ 64 bit, sequential code, lp64 model

Intel10_64ilp

New in version 3.13.

Intel MKL v10+ 64 bit, threaded code, ilp64 model

Intel10_64ilp_seq

New in version 3.13.

Intel MKL v10+ 64 bit, sequential code, ilp64 model

Intel10_64_dyn

New in version 3.17.

Intel MKL v10+ 64 bit, single dynamic library

NVHPC

New in version 3.21.

NVIDIA HPC SDK

OpenBLAS

New in version 3.6.

PhiPACK

Portable High Performance ANSI C (PHiPAC)

SCSL, SCSL_mp

Scientific Computing Software Library

SGIMATH

SGI Scientific Mathematical Library

SunPerf

Sun Performance Library

Intel MKL¶

To use the Intel MKL implementation of BLAS, a project must enable at least
one of the C or CXX languages.  Set BLA_VENDOR to an Intel MKL
variant either on the command-line as -DBLA_VENDOR=Intel10_64lp or in
project code:

set(BLA_VENDOR Intel10_64lp)
find_package(BLAS)

In order to build a project using Intel MKL, and end user must first
establish an Intel MKL environment:

Intel oneAPI

Source the full Intel environment script:

. /opt/intel/oneapi/setvars.sh

Or, source the MKL component environment script:

. /opt/intel/oneapi/mkl/latest/env/vars.sh

Intel Classic

Source the full Intel environment script:

. /opt/intel/bin/compilervars.sh intel64

Or, source the MKL component environment script:

. /opt/intel/mkl/bin/mklvars.sh intel64

The above environment scripts set the MKLROOT environment variable
to the top of the MKL installation.  They also add the location of the
runtime libraries to the dynamic library loader environment variable for
your platform (e.g. LD_LIBRARY_PATH).  This is necessary for programs
linked against MKL to run.

Note

As of Intel oneAPI 2021.2, loading only the MKL component does not
make all of its dependencies available.  In particular, the iomp5
library must be available separately, or provided by also loading
the compiler component environment:

. /opt/intel/oneapi/compiler/latest/env/vars.sh

Table of Contents

FindBLAS

Input Variables

Imported targets

Result Variables

BLAS/LAPACK Vendors

Intel MKL

Previous topic

FindBISON

Next topic

FindBoost

This Page

Show Source

Quick search

    <form class="search" action="../search.html" method="get">
      <input type="text" name="q" aria-labelledby="searchlabel" autocomplete="off" autocorrect="off" autocapitalize="off" spellcheck="false"/>
      <input type="submit" value="Go" />
    </form>

Navigation

          index

          next |

          previous |

    CMake »

    3.29.0-rc3 Documentation »

cmake-modules(7) »

FindBLAS

        © Copyright 2000-2024 Kitware, Inc. and Contributors.
      Created using Sphinx 6.2.1.


code:
<!DOCTYPE html>

    <meta charset="utf-8" />
    <meta name="viewport" content="width=device-width, initial-scale=1.0" /><meta name="generator" content="Docutils 0.19: https://docutils.sourceforge.io/" />

  <title>FindBZip2 — CMake 3.29.0-rc3 Documentation</title>

    <link rel="stylesheet" type="text/css" href="../_static/pygments.css" />
    <link rel="stylesheet" type="text/css" href="../_static/cmake.css" />

    <link rel="icon" href="../_static/cmake-favicon.ico"/>
    <link rel="index" title="Index" href="../genindex.html" />
    <link rel="search" title="Search" href="../search.html" />
    <link rel="next" title="FindCABLE" href="FindCABLE.html" />
    <link rel="prev" title="FindBullet" href="FindBullet.html" />

Navigation

          index

          next |

          previous |

    CMake »

    3.29.0-rc3 Documentation »

cmake-modules(7) »

FindBZip2

FindBZip2¶

Try to find BZip2

IMPORTED Targets¶

New in version 3.12.

This module defines IMPORTED target BZip2::BZip2, if
BZip2 has been found.

Result Variables¶

This module defines the following variables:

BZIP2_FOUND

system has BZip2

BZIP2_INCLUDE_DIRS

New in version 3.12: the BZip2 include directories

BZIP2_LIBRARIES

Link these to use BZip2

BZIP2_NEED_PREFIX

this is set if the functions are prefixed with BZ2_

BZIP2_VERSION

New in version 3.26: the version of BZip2 found.

See also legacy variable BZIP2_VERSION_STRING.

Cache variables¶

The following cache variables may also be set:

BZIP2_INCLUDE_DIR

the BZip2 include directory

Legacy Variables¶

The following variables are provided for backward compatibility:

BZIP2_VERSION_STRING

the version of BZip2 found.

Changed in version 3.26: Superseded by BZIP2_VERSION.

Table of Contents

FindBZip2

IMPORTED Targets

Result Variables

Cache variables

Legacy Variables

Previous topic

FindBullet

Next topic

FindCABLE

This Page

Show Source

Quick search

    <form class="search" action="../search.html" method="get">
      <input type="text" name="q" aria-labelledby="searchlabel" autocomplete="off" autocorrect="off" autocapitalize="off" spellcheck="false"/>
      <input type="submit" value="Go" />
    </form>

Navigation

          index

          next |

          previous |

    CMake »

    3.29.0-rc3 Documentation »

cmake-modules(7) »

FindBZip2

        © Copyright 2000-2024 Kitware, Inc. and Contributors.
      Created using Sphinx 6.2.1.


code:
<!DOCTYPE html>

    <meta charset="utf-8" />
    <meta name="viewport" content="width=device-width, initial-scale=1.0" /><meta name="generator" content="Docutils 0.19: https://docutils.sourceforge.io/" />

  <title>FindBacktrace — CMake 3.29.0-rc3 Documentation</title>

    <link rel="stylesheet" type="text/css" href="../_static/pygments.css" />
    <link rel="stylesheet" type="text/css" href="../_static/cmake.css" />

    <link rel="icon" href="../_static/cmake-favicon.ico"/>
    <link rel="index" title="Index" href="../genindex.html" />
    <link rel="search" title="Search" href="../search.html" />
    <link rel="next" title="FindBISON" href="FindBISON.html" />
    <link rel="prev" title="FindAVIFile" href="FindAVIFile.html" />

Navigation

          index

          next |

          previous |

    CMake »

    3.29.0-rc3 Documentation »

cmake-modules(7) »

FindBacktrace

FindBacktrace¶

Find provider for backtrace(3).

Checks if OS supports backtrace(3) via either libc or custom library.
This module defines the following variables:

Backtrace_HEADER

The header file needed for backtrace(3). Cached.
Could be forcibly set by user.

Backtrace_INCLUDE_DIRS

The include directories needed to use backtrace(3) header.

Backtrace_LIBRARIES

The libraries (linker flags) needed to use backtrace(3), if any.

Backtrace_FOUND

Is set if and only if backtrace(3) support detected.

The following cache variables are also available to set or use:

Backtrace_LIBRARY

The external library providing backtrace, if any.

Backtrace_INCLUDE_DIR

The directory holding the backtrace(3) header.

Typical usage is to generate of header file using configure_file()
with the contents like the following:

#cmakedefine01 Backtrace_FOUND
#if Backtrace_FOUND
# include <${Backtrace_HEADER}>
#endif

And then reference that generated header file in actual source.

Previous topic

FindAVIFile

Next topic

FindBISON

This Page

Show Source

Quick search

    <form class="search" action="../search.html" method="get">
      <input type="text" name="q" aria-labelledby="searchlabel" autocomplete="off" autocorrect="off" autocapitalize="off" spellcheck="false"/>
      <input type="submit" value="Go" />
    </form>

Navigation

          index

          next |

          previous |

    CMake »

    3.29.0-rc3 Documentation »

cmake-modules(7) »

FindBacktrace

        © Copyright 2000-2024 Kitware, Inc. and Contributors.
      Created using Sphinx 6.2.1.


code:
<!DOCTYPE html>

    <meta charset="utf-8" />
    <meta name="viewport" content="width=device-width, initial-scale=1.0" /><meta name="generator" content="Docutils 0.19: https://docutils.sourceforge.io/" />

  <title>FindBoost — CMake 3.29.0-rc3 Documentation</title>

    <link rel="stylesheet" type="text/css" href="../_static/pygments.css" />
    <link rel="stylesheet" type="text/css" href="../_static/cmake.css" />

    <link rel="icon" href="../_static/cmake-favicon.ico"/>
    <link rel="index" title="Index" href="../genindex.html" />
    <link rel="search" title="Search" href="../search.html" />
    <link rel="next" title="FindBullet" href="FindBullet.html" />
    <link rel="prev" title="FindBLAS" href="FindBLAS.html" />

Navigation

          index

          next |

          previous |

    CMake »

    3.29.0-rc3 Documentation »

cmake-modules(7) »

FindBoost

FindBoost¶

Find Boost include dirs and libraries

Use this module by invoking find_package() with the form:

find_package(Boost
  [version] [EXACT]      # Minimum or EXACT version e.g. 1.67.0
  [REQUIRED]             # Fail with error if Boost is not found
  [COMPONENTS <libs>...] # Boost libraries by their canonical name
                         # e.g. "date_time" for "libboost_date_time"
  [OPTIONAL_COMPONENTS <libs>...]
                         # Optional Boost libraries by their canonical name)
  )                      # e.g. "date_time" for "libboost_date_time"

This module finds headers and requested component libraries OR a CMake
package configuration file provided by a "Boost CMake" build.  For the
latter case skip to the Boost CMake section below.

New in version 3.7: bzip2 and zlib components (Windows only).

New in version 3.11: The OPTIONAL_COMPONENTS option.

New in version 3.13: stacktrace_* components.

New in version 3.19: bzip2 and zlib components on all platforms.

Result Variables¶

This module defines the following variables:

Boost_FOUND

True if headers and requested libraries were found.

Boost_INCLUDE_DIRS

Boost include directories.

Boost_LIBRARY_DIRS

Link directories for Boost libraries.

Boost_LIBRARIES

Boost component libraries to be linked.

Boost_<COMPONENT>_FOUND

True if component <COMPONENT> was found (<COMPONENT> name is upper-case).

Boost_<COMPONENT>_LIBRARY

Libraries to link for component <COMPONENT> (may include
target_link_libraries() debug/optimized keywords).

Boost_VERSION_MACRO

BOOST_VERSION value from boost/version.hpp.

Boost_VERSION_STRING

Boost version number in X.Y.Z format.

Boost_VERSION

Boost version number in X.Y.Z format (same as Boost_VERSION_STRING).

Changed in version 3.15: In previous CMake versions, this variable used the raw version string
from the Boost header (same as Boost_VERSION_MACRO).
See policy CMP0093.

Boost_LIB_VERSION

Version string appended to library filenames.

Boost_VERSION_MAJOR, Boost_MAJOR_VERSION

Boost major version number (X in X.Y.Z).

Boost_VERSION_MINOR, Boost_MINOR_VERSION

Boost minor version number (Y in X.Y.Z).

Boost_VERSION_PATCH, Boost_SUBMINOR_VERSION

Boost subminor version number (Z in X.Y.Z).

Boost_VERSION_COUNT

Amount of version components (3).

Boost_LIB_DIAGNOSTIC_DEFINITIONS (Windows-specific)

Pass to add_definitions() to have diagnostic
information about Boost's automatic linking
displayed during compilation

New in version 3.15: The Boost_VERSION_<PART> variables.

Cache variables¶

Search results are saved persistently in CMake cache entries:

Boost_INCLUDE_DIR

Directory containing Boost headers.

Boost_LIBRARY_DIR_RELEASE

Directory containing release Boost libraries.

Boost_LIBRARY_DIR_DEBUG

Directory containing debug Boost libraries.

Boost_<COMPONENT>_LIBRARY_DEBUG

Component <COMPONENT> library debug variant.

Boost_<COMPONENT>_LIBRARY_RELEASE

Component <COMPONENT> library release variant.

New in version 3.3: Per-configuration variables Boost_LIBRARY_DIR_RELEASE and
Boost_LIBRARY_DIR_DEBUG.

Hints¶

This module reads hints about search locations from variables:

BOOST_ROOT, BOOSTROOT

Preferred installation prefix.

BOOST_INCLUDEDIR

Preferred include directory e.g. <prefix>/include.

BOOST_LIBRARYDIR

Preferred library directory e.g. <prefix>/lib.

Boost_NO_SYSTEM_PATHS

Set to ON to disable searching in locations not
specified by these hint variables. Default is OFF.

Boost_ADDITIONAL_VERSIONS

List of Boost versions not known to this module.
(Boost install locations may contain the version).

Users may set these hints or results as CACHE entries.  Projects
should not read these entries directly but instead use the above
result variables.  Note that some hint names start in upper-case
BOOST.  One may specify these as environment variables if they are
not specified as CMake variables or cache entries.

This module first searches for the Boost header files using the above
hint variables (excluding BOOST_LIBRARYDIR) and saves the result in
Boost_INCLUDE_DIR.  Then it searches for requested component libraries
using the above hints (excluding BOOST_INCLUDEDIR and
Boost_ADDITIONAL_VERSIONS), "lib" directories near Boost_INCLUDE_DIR,
and the library name configuration settings below.  It saves the
library directories in Boost_LIBRARY_DIR_DEBUG and
Boost_LIBRARY_DIR_RELEASE and individual library
locations in Boost_<COMPONENT>_LIBRARY_DEBUG and Boost_<COMPONENT>_LIBRARY_RELEASE.
When one changes settings used by previous searches in the same build
tree (excluding environment variables) this module discards previous
search results affected by the changes and searches again.

Imported Targets¶

New in version 3.5.

This module defines the following IMPORTED targets:

Boost::boost

Target for header-only dependencies. (Boost include directory).

Boost::headers

New in version 3.15: Alias for Boost::boost.

Boost::<component>

Target for specific component dependency (shared or static library);
<component> name is lower-case.

Boost::diagnostic_definitions

Interface target to enable diagnostic information about Boost's automatic
linking during compilation (adds -DBOOST_LIB_DIAGNOSTIC).

Boost::disable_autolinking

Interface target to disable automatic linking with MSVC
(adds -DBOOST_ALL_NO_LIB).

Boost::dynamic_linking

Interface target to enable dynamic linking with MSVC
(adds -DBOOST_ALL_DYN_LINK).

Implicit dependencies such as Boost::filesystem requiring
Boost::system will be automatically detected and satisfied, even
if system is not specified when using find_package() and if
Boost::system is not added to target_link_libraries().  If using
Boost::thread, then Threads::Threads will also be added automatically.

It is important to note that the imported targets behave differently
than variables created by this module: multiple calls to
find_package(Boost) in the same directory or sub-directories with
different options (e.g. static or shared) will not override the
values of the targets created by the first call.

Other Variables¶

Boost libraries come in many variants encoded in their file name.
Users or projects may tell this module which variant to find by
setting variables:

Boost_USE_DEBUG_LIBS

New in version 3.10.

Set to ON or OFF to specify whether to search and use the debug
libraries.  Default is ON.

Boost_USE_RELEASE_LIBS

New in version 3.10.

Set to ON or OFF to specify whether to search and use the release
libraries.  Default is ON.

Boost_USE_MULTITHREADED

Set to OFF to use the non-multithreaded libraries ("mt" tag). Default is
ON.

Boost_USE_STATIC_LIBS

Set to ON to force the use of the static libraries.  Default is OFF.

Boost_USE_STATIC_RUNTIME

Set to ON or OFF to specify whether to use libraries linked
statically to the C++ runtime ("s" tag).  Default is platform dependent.

Boost_USE_DEBUG_RUNTIME

Set to ON or OFF to specify whether to use libraries linked to the
MS debug C++ runtime ("g" tag).  Default is ON.

Boost_USE_DEBUG_PYTHON

Set to ON to use libraries compiled with a debug Python build ("y"
tag).  Default is OFF.

Boost_USE_STLPORT

Set to ON to use libraries compiled with STLPort ("p" tag). Default is
OFF.

Boost_USE_STLPORT_DEPRECATED_NATIVE_IOSTREAMS

Set to ON to use libraries compiled with STLPort deprecated "native
iostreams" ("n" tag).  Default is OFF.

Boost_COMPILER

Set to the compiler-specific library suffix (e.g. -gcc43).  Default is
auto-computed for the C++ compiler in use.

Changed in version 3.9: A list may be used if multiple compatible suffixes should be tested for,
in decreasing order of preference.

Boost_LIB_PREFIX

New in version 3.18.

Set to the platform-specific library name prefix (e.g. lib) used by
Boost static libs.  This is needed only on platforms where CMake does not
know the prefix by default.

Boost_ARCHITECTURE

New in version 3.13.

Set to the architecture-specific library suffix (e.g. -x64).
Default is auto-computed for the C++ compiler in use.

Boost_THREADAPI

Suffix for thread component library name, such as pthread or
win32.  Names with and without this suffix will both be tried.

Boost_NAMESPACE

Alternate namespace used to build boost with e.g. if set to myboost,
will search for myboost_thread instead of boost_thread.

Other variables one may set to control this module are:

Boost_DEBUG

Set to ON to enable debug output from FindBoost.
Please enable this before filing any bug report.

Boost_REALPATH

Set to ON to resolve symlinks for discovered libraries to assist with
packaging.  For example, the "system" component library may be resolved to
/usr/lib/libboost_system.so.1.67.0 instead of
/usr/lib/libboost_system.so.  This does not affect linking and should
not be enabled unless the user needs this information.

Boost_LIBRARY_DIR

Default value for Boost_LIBRARY_DIR_RELEASE and
Boost_LIBRARY_DIR_DEBUG.

Boost_NO_WARN_NEW_VERSIONS

New in version 3.20.

Set to ON to suppress the warning about unknown dependencies for new
Boost versions.

On Visual Studio and Borland compilers Boost headers request automatic
linking to corresponding libraries.  This requires matching libraries
to be linked explicitly or available in the link library search path.
In this case setting Boost_USE_STATIC_LIBS to OFF may not achieve
dynamic linking.  Boost automatic linking typically requests static
libraries with a few exceptions (such as Boost.Python).  Use:

add_definitions(${Boost_LIB_DIAGNOSTIC_DEFINITIONS})

to ask Boost to report information about automatic linking requests.

Examples¶

Find Boost headers only:

find_package(Boost 1.36.0)
if(Boost_FOUND)
  include_directories(${Boost_INCLUDE_DIRS})
  add_executable(foo foo.cc)
endif()

Find Boost libraries and use imported targets:

find_package(Boost 1.56 REQUIRED COMPONENTS
             date_time filesystem iostreams)
add_executable(foo foo.cc)
target_link_libraries(foo Boost::date_time Boost::filesystem
                          Boost::iostreams)

Find Boost Python 3.6 libraries and use imported targets:

find_package(Boost 1.67 REQUIRED COMPONENTS
             python36 numpy36)
add_executable(foo foo.cc)
target_link_libraries(foo Boost::python36 Boost::numpy36)

Find Boost headers and some static (release only) libraries:

set(Boost_USE_STATIC_LIBS        ON)  # only find static libs
set(Boost_USE_DEBUG_LIBS        OFF)  # ignore debug libs and
set(Boost_USE_RELEASE_LIBS       ON)  # only find release libs
set(Boost_USE_MULTITHREADED      ON)
set(Boost_USE_STATIC_RUNTIME    OFF)
find_package(Boost 1.66.0 COMPONENTS date_time filesystem system ...)
if(Boost_FOUND)
  include_directories(${Boost_INCLUDE_DIRS})
  add_executable(foo foo.cc)
  target_link_libraries(foo ${Boost_LIBRARIES})
endif()

Boost CMake¶

If Boost was built using the boost-cmake project or from Boost 1.70.0 on
it provides a package configuration file for use with find_package's config mode.
This module looks for the package configuration file called
BoostConfig.cmake or boost-config.cmake and stores the result in
CACHE entry Boost_DIR.  If found, the package configuration file is loaded
and this module returns with no further action.  See documentation of
the Boost CMake package configuration for details on what it provides.

Set Boost_NO_BOOST_CMAKE to ON, to disable the search for boost-cmake.

Table of Contents

FindBoost

Result Variables

Cache variables

Hints

Imported Targets

Other Variables

Examples

Boost CMake

Previous topic

FindBLAS

Next topic

FindBullet

This Page

Show Source

Quick search

    <form class="search" action="../search.html" method="get">
      <input type="text" name="q" aria-labelledby="searchlabel" autocomplete="off" autocorrect="off" autocapitalize="off" spellcheck="false"/>
      <input type="submit" value="Go" />
    </form>

Navigation

          index

          next |

          previous |

    CMake »

    3.29.0-rc3 Documentation »

cmake-modules(7) »

FindBoost

        © Copyright 2000-2024 Kitware, Inc. and Contributors.
      Created using Sphinx 6.2.1.


code:
<!DOCTYPE html>

    <meta charset="utf-8" />
    <meta name="viewport" content="width=device-width, initial-scale=1.0" /><meta name="generator" content="Docutils 0.19: https://docutils.sourceforge.io/" />

  <title>FindBullet — CMake 3.29.0-rc3 Documentation</title>

    <link rel="stylesheet" type="text/css" href="../_static/pygments.css" />
    <link rel="stylesheet" type="text/css" href="../_static/cmake.css" />

    <link rel="icon" href="../_static/cmake-favicon.ico"/>
    <link rel="index" title="Index" href="../genindex.html" />
    <link rel="search" title="Search" href="../search.html" />
    <link rel="next" title="FindBZip2" href="FindBZip2.html" />
    <link rel="prev" title="FindBoost" href="FindBoost.html" />

Navigation

          index

          next |

          previous |

    CMake »

    3.29.0-rc3 Documentation »

cmake-modules(7) »

FindBullet

FindBullet¶

Try to find the Bullet physics engine

This module defines the following variables

BULLET_FOUND - Was bullet found
BULLET_INCLUDE_DIRS - the Bullet include directories
BULLET_LIBRARIES - Link to this, by default it includes
                   all bullet components (Dynamics,
                   Collision, LinearMath, & SoftBody)

This module accepts the following variables

BULLET_ROOT - Can be set to bullet install path or Windows build path

Previous topic

FindBoost

Next topic

FindBZip2

This Page

Show Source

Quick search

    <form class="search" action="../search.html" method="get">
      <input type="text" name="q" aria-labelledby="searchlabel" autocomplete="off" autocorrect="off" autocapitalize="off" spellcheck="false"/>
      <input type="submit" value="Go" />
    </form>

Navigation

          index

          next |

          previous |

    CMake »

    3.29.0-rc3 Documentation »

cmake-modules(7) »

FindBullet

        © Copyright 2000-2024 Kitware, Inc. and Contributors.
      Created using Sphinx 6.2.1.


code:
<!DOCTYPE html>

    <meta charset="utf-8" />
    <meta name="viewport" content="width=device-width, initial-scale=1.0" /><meta name="generator" content="Docutils 0.19: https://docutils.sourceforge.io/" />

  <title>FindCABLE — CMake 3.29.0-rc3 Documentation</title>

    <link rel="stylesheet" type="text/css" href="../_static/pygments.css" />
    <link rel="stylesheet" type="text/css" href="../_static/cmake.css" />

    <link rel="icon" href="../_static/cmake-favicon.ico"/>
    <link rel="index" title="Index" href="../genindex.html" />
    <link rel="search" title="Search" href="../search.html" />
    <link rel="next" title="FindCoin3D" href="FindCoin3D.html" />
    <link rel="prev" title="FindBZip2" href="FindBZip2.html" />

Navigation

          index

          next |

          previous |

    CMake »

    3.29.0-rc3 Documentation »

cmake-modules(7) »

FindCABLE

FindCABLE¶

Find CABLE

This module finds if CABLE is installed and determines where the
include files and libraries are.  This code sets the following
variables:

CABLE             the path to the cable executable
CABLE_TCL_LIBRARY the path to the Tcl wrapper library
CABLE_INCLUDE_DIR the path to the include directory

To build Tcl wrappers, you should add shared library and link it to
${CABLE_TCL_LIBRARY}.  You should also add ${CABLE_INCLUDE_DIR} as an
include directory.

Previous topic

FindBZip2

Next topic

FindCoin3D

This Page

Show Source

Quick search

    <form class="search" action="../search.html" method="get">
      <input type="text" name="q" aria-labelledby="searchlabel" autocomplete="off" autocorrect="off" autocapitalize="off" spellcheck="false"/>
      <input type="submit" value="Go" />
    </form>

Navigation

          index

          next |

          previous |

    CMake »

    3.29.0-rc3 Documentation »

cmake-modules(7) »

FindCABLE

        © Copyright 2000-2024 Kitware, Inc. and Contributors.
      Created using Sphinx 6.2.1.