CMAKE-MODULES(7) CMake CMAKE-MODULES(7)
NAME
cmake-modules - CMake Modules Reference
The modules listed here are part of the CMake distribution. Projects
may provide further modules; their location(s) can be specified in the
CMAKE_MODULE_PATH variable.
UTILITY MODULES
These modules are loaded using the include() command.
AddFileDependencies
Add dependencies to a source file.
ADD_FILE_DEPENDENCIES(<source> <files>)
Adds the given <files> to the dependencies of file <source>.
AndroidTestUtilities
Create a test that automatically loads specified data onto an Android
device.
Introduction
Use this module to push data needed for testing an Android device be-
havior onto a connected Android device. The module will accept files
and libraries as well as separate destinations for each. It will create
a test that loads the files into a device object store and link to them
from the specified destination. The files are only uploaded if they are
not already in the object store.
For example:
include(AndroidTestUtilities)
android_add_test_data(
example_setup_test
FILES <files>...
LIBS <libs>...
DEVICE_TEST_DIR "/data/local/tests/example"
DEVICE_OBJECT_STORE "/sdcard/.ExternalData/SHA"
)
At build time a test named example_setup_test will be created. Run
this test on the command line with ctest(1) to load the data onto the
Android device.
Module Functions
android_add_test_data
android_add_test_data(<test-name>
[FILES <files>...] [FILES_DEST <device-dir>]
[LIBS <libs>...] [LIBS_DEST <device-dir>]
[DEVICE_OBJECT_STORE <device-dir>]
[DEVICE_TEST_DIR <device-dir>]
[NO_LINK_REGEX <strings>...]
)
The android_add_test_data function is used to copy files and li-
braries needed to run project-specific tests. On the host oper-
ating system, this is done at build time. For on-device testing,
the files are loaded onto the device by the manufactured test at
run time.
This function accepts the following named parameters:
FILES <files>...
zero or more files needed for testing
LIBS <libs>...
zero or more libraries needed for testing
FILES_DEST <device-dir>
absolute path where the data files are expected to be
LIBS_DEST <device-dir>
absolute path where the libraries are expected to be
DEVICE_OBJECT_STORE <device-dir>
absolute path to the location where the data is stored
on-device
DEVICE_TEST_DIR <device-dir>
absolute path to the root directory of the on-device test
location
NO_LINK_REGEX <strings>...
list of regex strings matching the names of files that
should be copied from the object store to the testing di-
rectory
BundleUtilities
Functions to help assemble a standalone bundle application.
A collection of CMake utility functions useful for dealing with .app
bundles on the Mac and bundle-like directories on any OS.
The following functions are provided by this module:
fixup_bundle
copy_and_fixup_bundle
verify_app
get_bundle_main_executable
get_dotapp_dir
get_bundle_and_executable
get_bundle_all_executables
get_item_key
get_item_rpaths
clear_bundle_keys
set_bundle_key_values
get_bundle_keys
copy_resolved_item_into_bundle
copy_resolved_framework_into_bundle
fixup_bundle_item
verify_bundle_prerequisites
verify_bundle_symlinks
Requires CMake 2.6 or greater because it uses function, break and PAR-
ENT_SCOPE. Also depends on GetPrerequisites.cmake.
DO NOT USE THESE FUNCTIONS AT CONFIGURE TIME (from CMakeLists.txt)!
Instead, invoke them from an install(CODE) or install(SCRIPT) rule.
fixup_bundle(<app> <libs> <dirs>)
Fix up <app> bundle in-place and make it standalone, such that it can
be drag-n-drop copied to another machine and run on that machine as
long as all of the system libraries are compatible.
If you pass plugins to fixup_bundle as the libs parameter, you should
install them or copy them into the bundle before calling fixup_bundle.
The <libs> parameter is a list of libraries that must be fixed up, but
that cannot be determined by otool output analysis (i.e. plugins).
Gather all the keys for all the executables and libraries in a bundle,
and then, for each key, copy each prerequisite into the bundle. Then
fix each one up according to its own list of prerequisites.
Then clear all the keys and call verify_app on the final bundle to en-
sure that it is truly standalone.
As an optional parameter (IGNORE_ITEM) a list of file names can be
passed, which are then ignored (e.g. IGNORE_ITEM "vcre-
dist_x86.exe;vcredist_x64.exe").
copy_and_fixup_bundle(<src> <dst> <libs> <dirs>)
Makes a copy of the bundle <src> at location <dst> and then fixes up
the new copied bundle in-place at <dst>.
verify_app(<app>)
Verifies that an application <app> appears valid based on running
analysis tools on it. Calls message(FATAL_ERROR) if the application is
not verified.
As an optional parameter (IGNORE_ITEM) a list of file names can be
passed, which are then ignored (e.g. IGNORE_ITEM "vcre-
dist_x86.exe;vcredist_x64.exe")
get_bundle_main_executable(<bundle> <result_var>)
The result will be the full path name of the bundles main executable
file or an error: prefixed string if it could not be determined.
get_dotapp_dir(<exe> <dotapp_dir_var>)
Returns the nearest parent dir whose name ends with .app given the full
path to an executable. If there is no such parent dir, then simply re-
turn the dir containing the executable.
The returned directory may or may not exist.
get_bundle_and_executable(<app> <bundle_var> <executable_var> <valid_var>)
Takes either a .app directory name or the name of an executable nested
inside a .app directory and returns the path to the .app directory in
<bundle_var> and the path to its main executable in <executable_var>.
get_bundle_all_executables(<bundle> <exes_var>)
Scans <bundle> bundle recursively for all <exes_var> executable files
and accumulates them into a variable.
get_item_key(<item> <key_var>)
Given <item> file name, generate <key_var> key that should be unique
considering the set of libraries that need copying or fixing up to make
a bundle standalone. This is essentially the file name including ex-
tension with . replaced by _
This key is used as a p.
CMAKE-MODULES(7) CMake CMAKE-MODULES(7)
NAME
cmake-modules - CMake Modules Reference
The modules listed here are part of the CMake distribution. Projects
may provide further modules; their location(s) can be specified in the
CMAKE_MODULE_PATH variable.
UTILITY MODULES
These modules are loaded using the include() command.
AddFileDependencies
Add dependencies to a source file.
ADD_FILE_DEPENDENCIES(<source> <files>)
Adds the given <files> to the dependencies of file <source>.
AndroidTestUtilities
Create a test that automatically loads specified data onto an Android
device.
Introduction
Use this module to push data needed for testing an Android device be-
havior onto a connected Android device. The module will accept files
and libraries as well as separate destinations for each. It will create
a test that loads the files into a device object store and link to them
from the specified destination. The files are only uploaded if they are
not already in the object store.
For example:
include(AndroidTestUtilities)
android_add_test_data(
example_setup_test
FILES <files>...
LIBS <libs>...
DEVICE_TEST_DIR "/data/local/tests/example"
DEVICE_OBJECT_STORE "/sdcard/.ExternalData/SHA"
)
At build time a test named example_setup_test will be created. Run
this test on the command line with ctest(1) to load the data onto the
Android device.
Module Functions
android_add_test_data
android_add_test_data(<test-name>
[FILES <files>...] [FILES_DEST <device-dir>]
[LIBS <libs>...] [LIBS_DEST <device-dir>]
[DEVICE_OBJECT_STORE <device-dir>]
[DEVICE_TEST_DIR <device-dir>]
[NO_LINK_REGEX <strings>...]
)
The android_add_test_data function is used to copy files and li-
braries needed to run project-specific tests. On the host oper-
ating system, this is done at build time. For on-device testing,
the files are loaded onto the device by the manufactured test at
run time.
This function accepts the following named parameters:
FILES <files>...
zero or more files needed for testing
LIBS <libs>...
zero or more libraries needed for testing
FILES_DEST <device-dir>
absolute path where the data files are expected to be
LIBS_DEST <device-dir>
absolute path where the libraries are expected to be
DEVICE_OBJECT_STORE <device-dir>
absolute path to the location where the data is stored
on-device
DEVICE_TEST_DIR <device-dir>
absolute path to the root directory of the on-device test
location
NO_LINK_REGEX <strings>...
list of regex strings matching the names of files that
should be copied from the object store to the testing di-
rectory
BundleUtilities
Functions to help assemble a standalone bundle application.
A collection of CMake utility functions useful for dealing with .app
bundles on the Mac and bundle-like directories on any OS.
The following functions are provided by this module:
fixup_bundle
copy_and_fixup_bundle
verify_app
get_bundle_main_executable
get_dotapp_dir
get_bundle_and_executable
get_bundle_all_executables
get_item_key
get_item_rpaths
clear_bundle_keys
set_bundle_key_values
get_bundle_keys
copy_resolved_item_into_bundle
copy_resolved_framework_into_bundle
fixup_bundle_item
verify_bundle_prerequisites
verify_bundle_symlinks
Requires CMake 2.6 or greater because it uses function, break and PAR-
ENT_SCOPE. Also depends on GetPrerequisites.cmake.
DO NOT USE THESE FUNCTIONS AT CONFIGURE TIME (from CMakeLists.txt)!
Instead, invoke them from an install(CODE) or install(SCRIPT) rule.
fixup_bundle(<app> <libs> <dirs>)
Fix up <app> bundle in-place and make it standalone, such that it can
be drag-n-drop copied to another machine and run on that machine as
long as all of the system libraries are compatible.
If you pass plugins to fixup_bundle as the libs parameter, you should
install them or copy them into the bundle before calling fixup_bundle.
The <libs> parameter is a list of libraries that must be fixed up, but
that cannot be determined by otool output analysis (i.e. plugins).
Gather all the keys for all the executables and libraries in a bundle,
and then, for each key, copy each prerequisite into the bundle. Then
fix each one up according to its own list of prerequisites.
Then clear all the keys and call verify_app on the final bundle to en-
sure that it is truly standalone.
As an optional parameter (IGNORE_ITEM) a list of file names can be
passed, which are then ignored (e.g. IGNORE_ITEM "vcre-
dist_x86.exe;vcredist_x64.exe").
copy_and_fixup_bundle(<src> <dst> <libs> <dirs>)
Makes a copy of the bundle <src> at location <dst> and then fixes up
the new copied bundle in-place at <dst>.
verify_app(<app>)
Verifies that an application <app> appears valid based on running
analysis tools on it. Calls message(FATAL_ERROR) if the application is
not verified.
As an optional parameter (IGNORE_ITEM) a list of file names can be
passed, which are then ignored (e.g. IGNORE_ITEM "vcre-
dist_x86.exe;vcredist_x64.exe")
get_bundle_main_executable(<bundle> <result_var>)
The result will be the full path name of the bundles main executable
file or an error: prefixed string if it could not be determined.
get_dotapp_dir(<exe> <dotapp_dir_var>)
Returns the nearest parent dir whose name ends with .app given the full
path to an executable. If there is no such parent dir, then simply re-
turn the dir containing the executable.
The returned directory may or may not exist.
get_bundle_and_executable(<app> <bundle_var> <executable_var> <valid_var>)
Takes either a .app directory name or the name of an executable nested
inside a .app directory and returns the path to the .app directory in
<bundle_var> and the path to its main executable in <executable_var>.
get_bundle_all_executables(<bundle> <exes_var>)
Scans <bundle> bundle recursively for all <exes_var> executable files
and accumulates them into a variable.
get_item_key(<item> <key_var>)
Given <item> file name, generate <key_var> key that should be unique
considering the set of libraries that need copying or fixing up to make
a bundle standalone. This is essentially the file name including ex-
tension with . replaced by _
This key is used as a p.
CMAKE-MODULES(7) CMake CMAKE-MODULES(7)
NAME
cmake-modules - CMake Modules Reference
The modules listed here are part of the CMake distribution. Projects
may provide further modules; their location(s) can be specified in the
CMAKE_MODULE_PATH variable.
UTILITY MODULES
These modules are loaded using the include() command.
AddFileDependencies
Add dependencies to a source file.
ADD_FILE_DEPENDENCIES(<source> <files>)
Adds the given <files> to the dependencies of file <source>.
AndroidTestUtilities
Create a test that automatically loads specified data onto an Android
device.
Introduction
Use this module to push data needed for testing an Android device be-
havior onto a connected Android device. The module will accept files
and libraries as well as separate destinations for each. It will create
a test that loads the files into a device object store and link to them
from the specified destination. The files are only uploaded if they are
not already in the object store.
For example:
include(AndroidTestUtilities)
android_add_test_data(
example_setup_test
FILES <files>...
LIBS <libs>...
DEVICE_TEST_DIR "/data/local/tests/example"
DEVICE_OBJECT_STORE "/sdcard/.ExternalData/SHA"
)
At build time a test named example_setup_test will be created. Run
this test on the command line with ctest(1) to load the data onto the
Android device.
Module Functions
android_add_test_data
android_add_test_data(<test-name>
[FILES <files>...] [FILES_DEST <device-dir>]
[LIBS <libs>...] [LIBS_DEST <device-dir>]
[DEVICE_OBJECT_STORE <device-dir>]
[DEVICE_TEST_DIR <device-dir>]
[NO_LINK_REGEX <strings>...]
)
The android_add_test_data function is used to copy files and li-
braries needed to run project-specific tests. On the host oper-
ating system, this is done at build time. For on-device testing,
the files are loaded onto the device by the manufactured test at
run time.
This function accepts the following named parameters:
FILES <files>...
zero or more files needed for testing
LIBS <libs>...
zero or more libraries needed for testing
FILES_DEST <device-dir>
absolute path where the data files are expected to be
LIBS_DEST <device-dir>
absolute path where the libraries are expected to be
DEVICE_OBJECT_STORE <device-dir>
absolute path to the location where the data is stored
on-device
DEVICE_TEST_DIR <device-dir>
absolute path to the root directory of the on-device test
location
NO_LINK_REGEX <strings>...
list of regex strings matching the names of files that
should be copied from the object store to the testing di-
rectory
BundleUtilities
Functions to help assemble a standalone bundle application.
A collection of CMake utility functions useful for dealing with .app
bundles on the Mac and bundle-like directories on any OS.
The following functions are provided by this module:
fixup_bundle
copy_and_fixup_bundle
verify_app
get_bundle_main_executable
get_dotapp_dir
get_bundle_and_executable
get_bundle_all_executables
get_item_key
get_item_rpaths
clear_bundle_keys
set_bundle_key_values
get_bundle_keys
copy_resolved_item_into_bundle
copy_resolved_framework_into_bundle
fixup_bundle_item
verify_bundle_prerequisites
verify_bundle_symlinks
Requires CMake 2.6 or greater because it uses function, break and PAR-
ENT_SCOPE. Also depends on GetPrerequisites.cmake.
DO NOT USE THESE FUNCTIONS AT CONFIGURE TIME (from CMakeLists.txt)!
Instead, invoke them from an install(CODE) or install(SCRIPT) rule.
fixup_bundle(<app> <libs> <dirs>)
Fix up <app> bundle in-place and make it standalone, such that it can
be drag-n-drop copied to another machine and run on that machine as
long as all of the system libraries are compatible.
If you pass plugins to fixup_bundle as the libs parameter, you should
install them or copy them into the bundle before calling fixup_bundle.
The <libs> parameter is a list of libraries that must be fixed up, but
that cannot be determined by otool output analysis (i.e. plugins).
Gather all the keys for all the executables and libraries in a bundle,
and then, for each key, copy each prerequisite into the bundle. Then
fix each one up according to its own list of prerequisites.
Then clear all the keys and call verify_app on the final bundle to en-
sure that it is truly standalone.
As an optional parameter (IGNORE_ITEM) a list of file names can be
passed, which are then ignored (e.g. IGNORE_ITEM "vcre-
dist_x86.exe;vcredist_x64.exe").
copy_and_fixup_bundle(<src> <dst> <libs> <dirs>)
Makes a copy of the bundle <src> at location <dst> and then fixes up
the new copied bundle in-place at <dst>.
verify_app(<app>)
Verifies that an application <app> appears valid based on running
analysis tools on it. Calls message(FATAL_ERROR) if the application is
not verified.
As an optional parameter (IGNORE_ITEM) a list of file names can be
passed, which are then ignored (e.g. IGNORE_ITEM "vcre-
dist_x86.exe;vcredist_x64.exe")
get_bundle_main_executable(<bundle> <result_var>)
The result will be the full path name of the bundles main executable
file or an error: prefixed string if it could not be determined.
get_dotapp_dir(<exe> <dotapp_dir_var>)
Returns the nearest parent dir whose name ends with .app given the full
path to an executable. If there is no such parent dir, then simply re-
turn the dir containing the executable.
The returned directory may or may not exist.
get_bundle_and_executable(<app> <bundle_var> <executable_var> <valid_var>)
Takes either a .app directory name or the name of an executable nested
inside a .app directory and returns the path to the .app directory in
<bundle_var> and the path to its main executable in <executable_var>.
get_bundle_all_executables(<bundle> <exes_var>)
Scans <bundle> bundle recursively for all <exes_var> executable files
and accumulates them into a variable.
get_item_key(<item> <key_var>)
Given <item> file name, generate <key_var> key that should be unique
considering the set of libraries that need copying or fixing up to make
a bundle standalone. This is essentially the file name including ex-
tension with . replaced by _
This key is used as a p.
CMAKE-MODULES(7) CMake CMAKE-MODULES(7)
NAME
cmake-modules - CMake Modules Reference
The modules listed here are part of the CMake distribution. Projects
may provide further modules; their location(s) can be specified in the
CMAKE_MODULE_PATH variable.
UTILITY MODULES
These modules are loaded using the include() command.
AddFileDependencies
Add dependencies to a source file.
ADD_FILE_DEPENDENCIES(<source> <files>)
Adds the given <files> to the dependencies of file <source>.
AndroidTestUtilities
Create a test that automatically loads specified data onto an Android
device.
Introduction
Use this module to push data needed for testing an Android device be-
havior onto a connected Android device. The module will accept files
and libraries as well as separate destinations for each. It will create
a test that loads the files into a device object store and link to them
from the specified destination. The files are only uploaded if they are
not already in the object store.
For example:
include(AndroidTestUtilities)
android_add_test_data(
example_setup_test
FILES <files>...
LIBS <libs>...
DEVICE_TEST_DIR "/data/local/tests/example"
DEVICE_OBJECT_STORE "/sdcard/.ExternalData/SHA"
)
At build time a test named example_setup_test will be created. Run
this test on the command line with ctest(1) to load the data onto the
Android device.
Module Functions
android_add_test_data
android_add_test_data(<test-name>
[FILES <files>...] [FILES_DEST <device-dir>]
[LIBS <libs>...] [LIBS_DEST <device-dir>]
[DEVICE_OBJECT_STORE <device-dir>]
[DEVICE_TEST_DIR <device-dir>]
[NO_LINK_REGEX <strings>...]
)
The android_add_test_data function is used to copy files and li-
braries needed to run project-specific tests. On the host oper-
ating system, this is done at build time. For on-device testing,
the files are loaded onto the device by the manufactured test at
run time.
This function accepts the following named parameters:
FILES <files>...
zero or more files needed for testing
LIBS <libs>...
zero or more libraries needed for testing
FILES_DEST <device-dir>
absolute path where the data files are expected to be
LIBS_DEST <device-dir>
absolute path where the libraries are expected to be
DEVICE_OBJECT_STORE <device-dir>
absolute path to the location where the data is stored
on-device
DEVICE_TEST_DIR <device-dir>
absolute path to the root directory of the on-device test
location
NO_LINK_REGEX <strings>...
list of regex strings matching the names of files that
should be copied from the object store to the testing di-
rectory
BundleUtilities
Functions to help assemble a standalone bundle application.
A collection of CMake utility functions useful for dealing with .app
bundles on the Mac and bundle-like directories on any OS.
The following functions are provided by this module:
fixup_bundle
copy_and_fixup_bundle
verify_app
get_bundle_main_executable
get_dotapp_dir
get_bundle_and_executable
get_bundle_all_executables
get_item_key
get_item_rpaths
clear_bundle_keys
set_bundle_key_values
get_bundle_keys
copy_resolved_item_into_bundle
copy_resolved_framework_into_bundle
fixup_bundle_item
verify_bundle_prerequisites
verify_bundle_symlinks
Requires CMake 2.6 or greater because it uses function, break and PAR-
ENT_SCOPE. Also depends on GetPrerequisites.cmake.
DO NOT USE THESE FUNCTIONS AT CONFIGURE TIME (from CMakeLists.txt)!
Instead, invoke them from an install(CODE) or install(SCRIPT) rule.
fixup_bundle(<app> <libs> <dirs>)
Fix up <app> bundle in-place and make it standalone, such that it can
be drag-n-drop copied to another machine and run on that machine as
long as all of the system libraries are compatible.
If you pass plugins to fixup_bundle as the libs parameter, you should
install them or copy them into the bundle before calling fixup_bundle.
The <libs> parameter is a list of libraries that must be fixed up, but
that cannot be determined by otool output analysis (i.e. plugins).
Gather all the keys for all the executables and libraries in a bundle,
and then, for each key, copy each prerequisite into the bundle. Then
fix each one up according to its own list of prerequisites.
Then clear all the keys and call verify_app on the final bundle to en-
sure that it is truly standalone.
As an optional parameter (IGNORE_ITEM) a list of file names can be
passed, which are then ignored (e.g. IGNORE_ITEM "vcre-
dist_x86.exe;vcredist_x64.exe").
copy_and_fixup_bundle(<src> <dst> <libs> <dirs>)
Makes a copy of the bundle <src> at location <dst> and then fixes up
the new copied bundle in-place at <dst>.
verify_app(<app>)
Verifies that an application <app> appears valid based on running
analysis tools on it. Calls message(FATAL_ERROR) if the application is
not verified.
As an optional parameter (IGNORE_ITEM) a list of file names can be
passed, which are then ignored (e.g. IGNORE_ITEM "vcre-
dist_x86.exe;vcredist_x64.exe")
get_bundle_main_executable(<bundle> <result_var>)
The result will be the full path name of the bundles main executable
file or an error: prefixed string if it could not be determined.
get_dotapp_dir(<exe> <dotapp_dir_var>)
Returns the nearest parent dir whose name ends with .app given the full
path to an executable. If there is no such parent dir, then simply re-
turn the dir containing the executable.
The returned directory may or may not exist.
get_bundle_and_executable(<app> <bundle_var> <executable_var> <valid_var>)
Takes either a .app directory name or the name of an executable nested
inside a .app directory and returns the path to the .app directory in
<bundle_var> and the path to its main executable in <executable_var>.
get_bundle_all_executables(<bundle> <exes_var>)
Scans <bundle> bundle recursively for all <exes_var> executable files
and accumulates them into a variable.
get_item_key(<item> <key_var>)
Given <item> file name, generate <key_var> key that should be unique
considering the set of libraries that need copying or fixing up to make
a bundle standalone. This is essentially the file name including ex-
tension with . replaced by _
This key is used as a p.
CMAKE-MODULES(7) CMake CMAKE-MODULES(7)
NAME
cmake-modules - CMake Modules Reference
The modules listed here are part of the CMake distribution. Projects
may provide further modules; their location(s) can be specified in the
CMAKE_MODULE_PATH variable.
UTILITY MODULES
These modules are loaded using the include() command.
AddFileDependencies
Add dependencies to a source file.
ADD_FILE_DEPENDENCIES(<source> <files>)
Adds the given <files> to the dependencies of file <source>.
AndroidTestUtilities
Create a test that automatically loads specified data onto an Android
device.
Introduction
Use this module to push data needed for testing an Android device be-
havior onto a connected Android device. The module will accept files
and libraries as well as separate destinations for each. It will create
a test that loads the files into a device object store and link to them
from the specified destination. The files are only uploaded if they are
not already in the object store.
For example:
include(AndroidTestUtilities)
android_add_test_data(
example_setup_test
FILES <files>...
LIBS <libs>...
DEVICE_TEST_DIR "/data/local/tests/example"
DEVICE_OBJECT_STORE "/sdcard/.ExternalData/SHA"
)
At build time a test named example_setup_test will be created. Run
this test on the command line with ctest(1) to load the data onto the
Android device.
Module Functions
android_add_test_data
android_add_test_data(<test-name>
[FILES <files>...] [FILES_DEST <device-dir>]
[LIBS <libs>...] [LIBS_DEST <device-dir>]
[DEVICE_OBJECT_STORE <device-dir>]
[DEVICE_TEST_DIR <device-dir>]
[NO_LINK_REGEX <strings>...]
)
The android_add_test_data function is used to copy files and li-
braries needed to run project-specific tests. On the host oper-
ating system, this is done at build time. For on-device testing,
the files are loaded onto the device by the manufactured test at
run time.
This function accepts the following named parameters:
FILES <files>...
zero or more files needed for testing
LIBS <libs>...
zero or more libraries needed for testing
FILES_DEST <device-dir>
absolute path where the data files are expected to be
LIBS_DEST <device-dir>
absolute path where the libraries are expected to be
DEVICE_OBJECT_STORE <device-dir>
absolute path to the location where the data is stored
on-device
DEVICE_TEST_DIR <device-dir>
absolute path to the root directory of the on-device test
location
NO_LINK_REGEX <strings>...
list of regex strings matching the names of files that
should be copied from the object store to the testing di-
rectory
BundleUtilities
Functions to help assemble a standalone bundle application.
A collection of CMake utility functions useful for dealing with .app
bundles on the Mac and bundle-like directories on any OS.
The following functions are provided by this module:
fixup_bundle
copy_and_fixup_bundle
verify_app
get_bundle_main_executable
get_dotapp_dir
get_bundle_and_executable
get_bundle_all_executables
get_item_key
get_item_rpaths
clear_bundle_keys
set_bundle_key_values
get_bundle_keys
copy_resolved_item_into_bundle
copy_resolved_framework_into_bundle
fixup_bundle_item
verify_bundle_prerequisites
verify_bundle_symlinks
Requires CMake 2.6 or greater because it uses function, break and PAR-
ENT_SCOPE. Also depends on GetPrerequisites.cmake.
DO NOT USE THESE FUNCTIONS AT CONFIGURE TIME (from CMakeLists.txt)!
Instead, invoke them from an install(CODE) or install(SCRIPT) rule.
fixup_bundle(<app> <libs> <dirs>)
Fix up <app> bundle in-place and make it standalone, such that it can
be drag-n-drop copied to another machine and run on that machine as
long as all of the system libraries are compatible.
If you pass plugins to fixup_bundle as the libs parameter, you should
install them or copy them into the bundle before calling fixup_bundle.
The <libs> parameter is a list of libraries that must be fixed up, but
that cannot be determined by otool output analysis (i.e. plugins).
Gather all the keys for all the executables and libraries in a bundle,
and then, for each key, copy each prerequisite into the bundle. Then
fix each one up according to its own list of prerequisites.
Then clear all the keys and call verify_app on the final bundle to en-
sure that it is truly standalone.
As an optional parameter (IGNORE_ITEM) a list of file names can be
passed, which are then ignored (e.g. IGNORE_ITEM "vcre-
dist_x86.exe;vcredist_x64.exe").
copy_and_fixup_bundle(<src> <dst> <libs> <dirs>)
Makes a copy of the bundle <src> at location <dst> and then fixes up
the new copied bundle in-place at <dst>.
verify_app(<app>)
Verifies that an application <app> appears valid based on running
analysis tools on it. Calls message(FATAL_ERROR) if the application is
not verified.
As an optional parameter (IGNORE_ITEM) a list of file names can be
passed, which are then ignored (e.g. IGNORE_ITEM "vcre-
dist_x86.exe;vcredist_x64.exe")
get_bundle_main_executable(<bundle> <result_var>)
The result will be the full path name of the bundles main executable
file or an error: prefixed string if it could not be determined.
get_dotapp_dir(<exe> <dotapp_dir_var>)
Returns the nearest parent dir whose name ends with .app given the full
path to an executable. If there is no such parent dir, then simply re-
turn the dir containing the executable.
The returned directory may or may not exist.
get_bundle_and_executable(<app> <bundle_var> <executable_var> <valid_var>)
Takes either a .app directory name or the name of an executable nested
inside a .app directory and returns the path to the .app directory in
<bundle_var> and the path to its main executable in <executable_var>.
get_bundle_all_executables(<bundle> <exes_var>)
Scans <bundle> bundle recursively for all <exes_var> executable files
and accumulates them into a variable.
get_item_key(<item> <key_var>)
Given <item> file name, generate <key_var> key that should be unique
considering the set of libraries that need copying or fixing up to make
a bundle standalone. This is essentially the file name including ex-
tension with . replaced by _
This key is used as a p.
CMAKE-MODULES(7) CMake CMAKE-MODULES(7)
NAME
cmake-modules - CMake Modules Reference
The modules listed here are part of the CMake distribution. Projects
may provide further modules; their location(s) can be specified in the
CMAKE_MODULE_PATH variable.
UTILITY MODULES
These modules are loaded using the include() command.
AddFileDependencies
Add dependencies to a source file.
ADD_FILE_DEPENDENCIES(<source> <files>)
Adds the given <files> to the dependencies of file <source>.
AndroidTestUtilities
Create a test that automatically loads specified data onto an Android
device.
Introduction
Use this module to push data needed for testing an Android device be-
havior onto a connected Android device. The module will accept files
and libraries as well as separate destinations for each. It will create
a test that loads the files into a device object store and link to them
from the specified destination. The files are only uploaded if they are
not already in the object store.
For example:
include(AndroidTestUtilities)
android_add_test_data(
example_setup_test
FILES <files>...
LIBS <libs>...
DEVICE_TEST_DIR "/data/local/tests/example"
DEVICE_OBJECT_STORE "/sdcard/.ExternalData/SHA"
)
At build time a test named example_setup_test will be created. Run
this test on the command line with ctest(1) to load the data onto the
Android device.
Module Functions
android_add_test_data
android_add_test_data(<test-name>
[FILES <files>...] [FILES_DEST <device-dir>]
[LIBS <libs>...] [LIBS_DEST <device-dir>]
[DEVICE_OBJECT_STORE <device-dir>]
[DEVICE_TEST_DIR <device-dir>]
[NO_LINK_REGEX <strings>...]
)
The android_add_test_data function is used to copy files and li-
braries needed to run project-specific tests. On the host oper-
ating system, this is done at build time. For on-device testing,
the files are loaded onto the device by the manufactured test at
run time.
This function accepts the following named parameters:
FILES <files>...
zero or more files needed for testing
LIBS <libs>...
zero or more libraries needed for testing
FILES_DEST <device-dir>
absolute path where the data files are expected to be
LIBS_DEST <device-dir>
absolute path where the libraries are expected to be
DEVICE_OBJECT_STORE <device-dir>
absolute path to the location where the data is stored
on-device
DEVICE_TEST_DIR <device-dir>
absolute path to the root directory of the on-device test
location
NO_LINK_REGEX <strings>...
list of regex strings matching the names of files that
should be copied from the object store to the testing di-
rectory
BundleUtilities
Functions to help assemble a standalone bundle application.
A collection of CMake utility functions useful for dealing with .app
bundles on the Mac and bundle-like directories on any OS.
The following functions are provided by this module:
fixup_bundle
copy_and_fixup_bundle
verify_app
get_bundle_main_executable
get_dotapp_dir
get_bundle_and_executable
get_bundle_all_executables
get_item_key
get_item_rpaths
clear_bundle_keys
set_bundle_key_values
get_bundle_keys
copy_resolved_item_into_bundle
copy_resolved_framework_into_bundle
fixup_bundle_item
verify_bundle_prerequisites
verify_bundle_symlinks
Requires CMake 2.6 or greater because it uses function, break and PAR-
ENT_SCOPE. Also depends on GetPrerequisites.cmake.
DO NOT USE THESE FUNCTIONS AT CONFIGURE TIME (from CMakeLists.txt)!
Instead, invoke them from an install(CODE) or install(SCRIPT) rule.
fixup_bundle(<app> <libs> <dirs>)
Fix up <app> bundle in-place and make it standalone, such that it can
be drag-n-drop copied to another machine and run on that machine as
long as all of the system libraries are compatible.
If you pass plugins to fixup_bundle as the libs parameter, you should
install them or copy them into the bundle before calling fixup_bundle.
The <libs> parameter is a list of libraries that must be fixed up, but
that cannot be determined by otool output analysis (i.e. plugins).
Gather all the keys for all the executables and libraries in a bundle,
and then, for each key, copy each prerequisite into the bundle. Then
fix each one up according to its own list of prerequisites.
Then clear all the keys and call verify_app on the final bundle to en-
sure that it is truly standalone.
As an optional parameter (IGNORE_ITEM) a list of file names can be
passed, which are then ignored (e.g. IGNORE_ITEM "vcre-
dist_x86.exe;vcredist_x64.exe").
copy_and_fixup_bundle(<src> <dst> <libs> <dirs>)
Makes a copy of the bundle <src> at location <dst> and then fixes up
the new copied bundle in-place at <dst>.
verify_app(<app>)
Verifies that an application <app> appears valid based on running
analysis tools on it. Calls message(FATAL_ERROR) if the application is
not verified.
As an optional parameter (IGNORE_ITEM) a list of file names can be
passed, which are then ignored (e.g. IGNORE_ITEM "vcre-
dist_x86.exe;vcredist_x64.exe")
get_bundle_main_executable(<bundle> <result_var>)
The result will be the full path name of the bundles main executable
file or an error: prefixed string if it could not be determined.
get_dotapp_dir(<exe> <dotapp_dir_var>)
Returns the nearest parent dir whose name ends with .app given the full
path to an executable. If there is no such parent dir, then simply re-
turn the dir containing the executable.
The returned directory may or may not exist.
get_bundle_and_executable(<app> <bundle_var> <executable_var> <valid_var>)
Takes either a .app directory name or the name of an executable nested
inside a .app directory and returns the path to the .app directory in
<bundle_var> and the path to its main executable in <executable_var>.
get_bundle_all_executables(<bundle> <exes_var>)
Scans <bundle> bundle recursively for all <exes_var> executable files
and accumulates them into a variable.
get_item_key(<item> <key_var>)
Given <item> file name, generate <key_var> key that should be unique
considering the set of libraries that need copying or fixing up to make
a bundle standalone. This is essentially the file name including ex-
tension with . replaced by _
This key is used as a p.
CMAKE-MODULES(7) CMake CMAKE-MODULES(7)
NAME
cmake-modules - CMake Modules Reference
The modules listed here are part of the CMake distribution. Projects
may provide further modules; their location(s) can be specified in the
CMAKE_MODULE_PATH variable.
UTILITY MODULES
These modules are loaded using the include() command.
AddFileDependencies
Add dependencies to a source file.
ADD_FILE_DEPENDENCIES(<source> <files>)
Adds the given <files> to the dependencies of file <source>.
AndroidTestUtilities
Create a test that automatically loads specified data onto an Android
device.
Introduction
Use this module to push data needed for testing an Android device be-
havior onto a connected Android device. The module will accept files
and libraries as well as separate destinations for each. It will create
a test that loads the files into a device object store and link to them
from the specified destination. The files are only uploaded if they are
not already in the object store.
For example:
include(AndroidTestUtilities)
android_add_test_data(
example_setup_test
FILES <files>...
LIBS <libs>...
DEVICE_TEST_DIR "/data/local/tests/example"
DEVICE_OBJECT_STORE "/sdcard/.ExternalData/SHA"
)
At build time a test named example_setup_test will be created. Run
this test on the command line with ctest(1) to load the data onto the
Android device.
Module Functions
android_add_test_data
android_add_test_data(<test-name>
[FILES <files>...] [FILES_DEST <device-dir>]
[LIBS <libs>...] [LIBS_DEST <device-dir>]
[DEVICE_OBJECT_STORE <device-dir>]
[DEVICE_TEST_DIR <device-dir>]
[NO_LINK_REGEX <strings>...]
)
The android_add_test_data function is used to copy files and li-
braries needed to run project-specific tests. On the host oper-
ating system, this is done at build time. For on-device testing,
the files are loaded onto the device by the manufactured test at
run time.
This function accepts the following named parameters:
FILES <files>...
zero or more files needed for testing
LIBS <libs>...
zero or more libraries needed for testing
FILES_DEST <device-dir>
absolute path where the data files are expected to be
LIBS_DEST <device-dir>
absolute path where the libraries are expected to be
DEVICE_OBJECT_STORE <device-dir>
absolute path to the location where the data is stored
on-device
DEVICE_TEST_DIR <device-dir>
absolute path to the root directory of the on-device test
location
NO_LINK_REGEX <strings>...
list of regex strings matching the names of files that
should be copied from the object store to the testing di-
rectory
BundleUtilities
Functions to help assemble a standalone bundle application.
A collection of CMake utility functions useful for dealing with .app
bundles on the Mac and bundle-like directories on any OS.
The following functions are provided by this module:
fixup_bundle
copy_and_fixup_bundle
verify_app
get_bundle_main_executable
get_dotapp_dir
get_bundle_and_executable
get_bundle_all_executables
get_item_key
get_item_rpaths
clear_bundle_keys
set_bundle_key_values
get_bundle_keys
copy_resolved_item_into_bundle
copy_resolved_framework_into_bundle
fixup_bundle_item
verify_bundle_prerequisites
verify_bundle_symlinks
Requires CMake 2.6 or greater because it uses function, break and PAR-
ENT_SCOPE. Also depends on GetPrerequisites.cmake.
DO NOT USE THESE FUNCTIONS AT CONFIGURE TIME (from CMakeLists.txt)!
Instead, invoke them from an install(CODE) or install(SCRIPT) rule.
fixup_bundle(<app> <libs> <dirs>)
Fix up <app> bundle in-place and make it standalone, such that it can
be drag-n-drop copied to another machine and run on that machine as
long as all of the system libraries are compatible.
If you pass plugins to fixup_bundle as the libs parameter, you should
install them or copy them into the bundle before calling fixup_bundle.
The <libs> parameter is a list of libraries that must be fixed up, but
that cannot be determined by otool output analysis (i.e. plugins).
Gather all the keys for all the executables and libraries in a bundle,
and then, for each key, copy each prerequisite into the bundle. Then
fix each one up according to its own list of prerequisites.
Then clear all the keys and call verify_app on the final bundle to en-
sure that it is truly standalone.
As an optional parameter (IGNORE_ITEM) a list of file names can be
passed, which are then ignored (e.g. IGNORE_ITEM "vcre-
dist_x86.exe;vcredist_x64.exe").
copy_and_fixup_bundle(<src> <dst> <libs> <dirs>)
Makes a copy of the bundle <src> at location <dst> and then fixes up
the new copied bundle in-place at <dst>.
verify_app(<app>)
Verifies that an application <app> appears valid based on running
analysis tools on it. Calls message(FATAL_ERROR) if the application is
not verified.
As an optional parameter (IGNORE_ITEM) a list of file names can be
passed, which are then ignored (e.g. IGNORE_ITEM "vcre-
dist_x86.exe;vcredist_x64.exe")
get_bundle_main_executable(<bundle> <result_var>)
The result will be the full path name of the bundles main executable
file or an error: prefixed string if it could not be determined.
get_dotapp_dir(<exe> <dotapp_dir_var>)
Returns the nearest parent dir whose name ends with .app given the full
path to an executable. If there is no such parent dir, then simply re-
turn the dir containing the executable.
The returned directory may or may not exist.
get_bundle_and_executable(<app> <bundle_var> <executable_var> <valid_var>)
Takes either a .app directory name or the name of an executable nested
inside a .app directory and returns the path to the .app directory in
<bundle_var> and the path to its main executable in <executable_var>.
get_bundle_all_executables(<bundle> <exes_var>)
Scans <bundle> bundle recursively for all <exes_var> executable files
and accumulates them into a variable.
get_item_key(<item> <key_var>)
Given <item> file name, generate <key_var> key that should be unique
considering the set of libraries that need copying or fixing up to make
a bundle standalone. This is essentially the file name including ex-
tension with . replaced by _
This key is used as a p.
CMAKE-MODULES(7) CMake CMAKE-MODULES(7)
NAME
cmake-modules - CMake Modules Reference
The modules listed here are part of the CMake distribution. Projects
may provide further modules; their location(s) can be specified in the
CMAKE_MODULE_PATH variable.
UTILITY MODULES
These modules are loaded using the include() command.
AddFileDependencies
Add dependencies to a source file.
ADD_FILE_DEPENDENCIES(<source> <files>)
Adds the given <files> to the dependencies of file <source>.
AndroidTestUtilities
Create a test that automatically loads specified data onto an Android
device.
Introduction
Use this module to push data needed for testing an Android device be-
havior onto a connected Android device. The module will accept files
and libraries as well as separate destinations for each. It will create
a test that loads the files into a device object store and link to them
from the specified destination. The files are only uploaded if they are
not already in the object store.
For example:
include(AndroidTestUtilities)
android_add_test_data(
example_setup_test
FILES <files>...
LIBS <libs>...
DEVICE_TEST_DIR "/data/local/tests/example"
DEVICE_OBJECT_STORE "/sdcard/.ExternalData/SHA"
)
At build time a test named example_setup_test will be created. Run
this test on the command line with ctest(1) to load the data onto the
Android device.
Module Functions
android_add_test_data
android_add_test_data(<test-name>
[FILES <files>...] [FILES_DEST <device-dir>]
[LIBS <libs>...] [LIBS_DEST <device-dir>]
[DEVICE_OBJECT_STORE <device-dir>]
[DEVICE_TEST_DIR <device-dir>]
[NO_LINK_REGEX <strings>...]
)
The android_add_test_data function is used to copy files and li-
braries needed to run project-specific tests. On the host oper-
ating system, this is done at build time. For on-device testing,
the files are loaded onto the device by the manufactured test at
run time.
This function accepts the following named parameters:
FILES <files>...
zero or more files needed for testing
LIBS <libs>...
zero or more libraries needed for testing
FILES_DEST <device-dir>
absolute path where the data files are expected to be
LIBS_DEST <device-dir>
absolute path where the libraries are expected to be
DEVICE_OBJECT_STORE <device-dir>
absolute path to the location where the data is stored
on-device
DEVICE_TEST_DIR <device-dir>
absolute path to the root directory of the on-device test
location
NO_LINK_REGEX <strings>...
list of regex strings matching the names of files that
should be copied from the object store to the testing di-
rectory
BundleUtilities
Functions to help assemble a standalone bundle application.
A collection of CMake utility functions useful for dealing with .app
bundles on the Mac and bundle-like directories on any OS.
The following functions are provided by this module:
fixup_bundle
copy_and_fixup_bundle
verify_app
get_bundle_main_executable
get_dotapp_dir
get_bundle_and_executable
get_bundle_all_executables
get_item_key
get_item_rpaths
clear_bundle_keys
set_bundle_key_values
get_bundle_keys
copy_resolved_item_into_bundle
copy_resolved_framework_into_bundle
fixup_bundle_item
verify_bundle_prerequisites
verify_bundle_symlinks
Requires CMake 2.6 or greater because it uses function, break and PAR-
ENT_SCOPE. Also depends on GetPrerequisites.cmake.
DO NOT USE THESE FUNCTIONS AT CONFIGURE TIME (from CMakeLists.txt)!
Instead, invoke them from an install(CODE) or install(SCRIPT) rule.
fixup_bundle(<app> <libs> <dirs>)
Fix up <app> bundle in-place and make it standalone, such that it can
be drag-n-drop copied to another machine and run on that machine as
long as all of the system libraries are compatible.
If you pass plugins to fixup_bundle as the libs parameter, you should
install them or copy them into the bundle before calling fixup_bundle.
The <libs> parameter is a list of libraries that must be fixed up, but
that cannot be determined by otool output analysis (i.e. plugins).
Gather all the keys for all the executables and libraries in a bundle,
and then, for each key, copy each prerequisite into the bundle. Then
fix each one up according to its own list of prerequisites.
Then clear all the keys and call verify_app on the final bundle to en-
sure that it is truly standalone.
As an optional parameter (IGNORE_ITEM) a list of file names can be
passed, which are then ignored (e.g. IGNORE_ITEM "vcre-
dist_x86.exe;vcredist_x64.exe").
copy_and_fixup_bundle(<src> <dst> <libs> <dirs>)
Makes a copy of the bundle <src> at location <dst> and then fixes up
the new copied bundle in-place at <dst>.
verify_app(<app>)
Verifies that an application <app> appears valid based on running
analysis tools on it. Calls message(FATAL_ERROR) if the application is
not verified.
As an optional parameter (IGNORE_ITEM) a list of file names can be
passed, which are then ignored (e.g. IGNORE_ITEM "vcre-
dist_x86.exe;vcredist_x64.exe")
get_bundle_main_executable(<bundle> <result_var>)
The result will be the full path name of the bundles main executable
file or an error: prefixed string if it could not be determined.
get_dotapp_dir(<exe> <dotapp_dir_var>)
Returns the nearest parent dir whose name ends with .app given the full
path to an executable. If there is no such parent dir, then simply re-
turn the dir containing the executable.
The returned directory may or may not exist.
get_bundle_and_executable(<app> <bundle_var> <executable_var> <valid_var>)
Takes either a .app directory name or the name of an executable nested
inside a .app directory and returns the path to the .app directory in
<bundle_var> and the path to its main executable in <executable_var>.
get_bundle_all_executables(<bundle> <exes_var>)
Scans <bundle> bundle recursively for all <exes_var> executable files
and accumulates them into a variable.
get_item_key(<item> <key_var>)
Given <item> file name, generate <key_var> key that should be unique
considering the set of libraries that need copying or fixing up to make
a bundle standalone. This is essentially the file name including ex-
tension with . replaced by _
This key is used as a p.
CMAKE-MODULES(7) CMake CMAKE-MODULES(7)
NAME
cmake-modules - CMake Modules Reference
3.18.4 September 13, 2021 CMAKE-MODULES(7)
Czas wygenerowania: 0.00081 sek.
Created with the man page lookup class by Andrew Collington.
Based on a C man page viewer by Vadim Pavlov
Unicode soft-hyphen fix (as used by RedHat) by Dan Edwards
Some optimisations by Eli Argon
Caching idea and code contribution by James Richardson
Copyright © 2003-2025 Linux.pl
Hosted by Hosting Linux.pl