... | @@ -34,11 +34,11 @@ |
... | @@ -34,11 +34,11 @@ |
|
* [How can I generate a source file during the build?](#how-can-i-generate-a-source-file-during-the-build)
|
|
* [How can I generate a source file during the build?](#how-can-i-generate-a-source-file-during-the-build)
|
|
* [How can I add a dependency to a source file which is generated in a subdirectory?](#how-can-i-add-a-dependency-to-a-source-file-which-is-generated-in-a-subdirectory)
|
|
* [How can I add a dependency to a source file which is generated in a subdirectory?](#how-can-i-add-a-dependency-to-a-source-file-which-is-generated-in-a-subdirectory)
|
|
* [How can I generate a file used in more than one target in the same directory?](#how-can-i-generate-a-file-used-in-more-than-one-target-in-the-same-directory)
|
|
* [How can I generate a file used in more than one target in the same directory?](#how-can-i-generate-a-file-used-in-more-than-one-target-in-the-same-directory)
|
|
* [I use EXEC_PROGRAM but the result is not set in subdirectories. Why?](#i-use-exec_program-but-the-result-is-not-set-in-subdirectories-why)
|
|
* [I use exec_program but the result is not set in subdirectories. Why?](#i-use-exec_program-but-the-result-is-not-set-in-subdirectories-why)
|
|
* [How can I get or set environment variables?](#how-can-i-get-or-set-environment-variables)
|
|
* [How can I get or set environment variables?](#how-can-i-get-or-set-environment-variables)
|
|
* [Why do I have unwanted semicolons ; in my compiler flags?](#why-do-i-have-unwanted-semicolons-in-my-compiler-flags)
|
|
* [Why do I have unwanted semicolons ; in my compiler flags?](#why-do-i-have-unwanted-semicolons-in-my-compiler-flags)
|
|
* [How can I get quoting and escapes to work properly?](#how-can-i-get-quoting-and-escapes-to-work-properly)
|
|
* [How can I get quoting and escapes to work properly?](#how-can-i-get-quoting-and-escapes-to-work-properly)
|
|
* [Isn't the "Expression" in the "ELSE (Expression)" confusing?](#isnt-the-expression-in-the-else-expression-confusing)
|
|
* [Isn't the "Expression" in the "else(Expression)" confusing?](#isnt-the-expression-in-the-else-expression-confusing)
|
|
* [Which regular expressions are supported by CMake?](#which-regular-expressions-are-supported-by-cmake)
|
|
* [Which regular expressions are supported by CMake?](#which-regular-expressions-are-supported-by-cmake)
|
|
* [How to convert a semicolon separated list to a whitespace separated string?](#how-to-convert-a-semicolon-separated-list-to-a-whitespace-separated-string)
|
|
* [How to convert a semicolon separated list to a whitespace separated string?](#how-to-convert-a-semicolon-separated-list-to-a-whitespace-separated-string)
|
|
* [How can I build multiple modes without switching ?](#how-can-i-build-multiple-modes-without-switching-)
|
|
* [How can I build multiple modes without switching ?](#how-can-i-build-multiple-modes-without-switching-)
|
... | @@ -71,7 +71,7 @@ |
... | @@ -71,7 +71,7 @@ |
|
- [Platform-specific questions](#platform-specific-questions)
|
|
- [Platform-specific questions](#platform-specific-questions)
|
|
* [How do I build universal binaries on Mac OS X?](#how-do-i-build-universal-binaries-on-mac-os-x)
|
|
* [How do I build universal binaries on Mac OS X?](#how-do-i-build-universal-binaries-on-mac-os-x)
|
|
* [How can I apply resources on Mac OS X automatically?](#how-can-i-apply-resources-on-mac-os-x-automatically)
|
|
* [How can I apply resources on Mac OS X automatically?](#how-can-i-apply-resources-on-mac-os-x-automatically)
|
|
* [Why does FIND_LIBRARY not find .DLL libraries under WIN32?](#why-does-find_library-not-find-dll-libraries-under-win32)
|
|
* [Why does find_library not find .DLL libraries under WIN32?](#why-does-find_library-not-find-dll-libraries-under-win32)
|
|
* [Why am I getting a linker error to _mainCRTStartup under WIN32?](#why-am-i-getting-a-linker-error-to-_maincrtstartup-under-win32)
|
|
* [Why am I getting a linker error to _mainCRTStartup under WIN32?](#why-am-i-getting-a-linker-error-to-_maincrtstartup-under-win32)
|
|
* [Why do I get this error: nafxcwd.lib(appcore.obj) : error LNK2001: unresolved external symbol ___argv](#why-do-i-get-this-error-nafxcwdlibappcoreobj-error-lnk2001-unresolved-external-symbol-___argv)
|
|
* [Why do I get this error: nafxcwd.lib(appcore.obj) : error LNK2001: unresolved external symbol ___argv](#why-do-i-get-this-error-nafxcwdlibappcoreobj-error-lnk2001-unresolved-external-symbol-___argv)
|
|
* [How to use MFC with CMake](#how-to-use-mfc-with-cmake)
|
|
* [How to use MFC with CMake](#how-to-use-mfc-with-cmake)
|
... | @@ -147,14 +147,13 @@ released which documents CMake 2.6. |
... | @@ -147,14 +147,13 @@ released which documents CMake 2.6. |
|
|
|
|
|
The following features have been added since printing the book:
|
|
The following features have been added since printing the book:
|
|
|
|
|
|
- New INSTALL command (cmake --help-command INSTALL)
|
|
- New `install` command (`cmake --help-command install`)
|
|
- New LIST command (cmake --help-command LIST)
|
|
- New `list` command (`cmake --help-command list`)
|
|
- Updated FIND_PATH, FIND_PROGRAM, and FIND_FILE commands to be
|
|
- Updated `find_path`, `find_program`, and `find_file` commands to be
|
|
more powerful (cmake --help-command FIND_PATH)
|
|
more powerful (`cmake --help-command find_path`)
|
|
- RPATH and Mac OS X install_name support (cmake --help-command
|
|
- RPATH and Mac OS X install_name support (`cmake --help-command set_target_properties`)
|
|
SET_TARGET_PROPERTIES)
|
|
|
|
- CPack Beta (not finished or documented)
|
|
- CPack Beta (not finished or documented)
|
|
- EXECUTE_PROCESS was added and replaces EXEC_PROGRAM
|
|
- `execute_process` was added and replaces `exec_program`
|
|
- Other changes have been bug fixes and internal CMake restructuring
|
|
- Other changes have been bug fixes and internal CMake restructuring
|
|
|
|
|
|
### Where can I find searchable CMake Mailing Archives?
|
|
### Where can I find searchable CMake Mailing Archives?
|
... | @@ -176,25 +175,29 @@ There exist at least these ones: |
... | @@ -176,25 +175,29 @@ There exist at least these ones: |
|
|
|
|
|
### Is there an option to produce more 'verbose' compiling?
|
|
### Is there an option to produce more 'verbose' compiling?
|
|
|
|
|
|
On Makefile generators, you can set the Makefile variable VERBOSE to 1.
|
|
On Makefile generators, you can set the Makefile variable `VERBOSE` to 1.
|
|
For example on UNIX:
|
|
For example on UNIX:
|
|
|
|
```shell
|
|
|
|
make VERBOSE=1
|
|
|
|
```
|
|
|
|
|
|
make VERBOSE=1
|
|
You can also set `CMAKE_VERBOSE_MAKEFILE` to ON.
|
|
|
|
|
|
You can also set CMAKE_VERBOSE_MAKEFILE to ON.
|
|
|
|
|
|
|
|
On Windows (nmake) you can override CMAKE_VERBOSE_MAKEFILE by using
|
|
|
|
|
|
|
|
nmake /S
|
|
On Windows (nmake) you can override `CMAKE_VERBOSE_MAKEFILE` by using
|
|
|
|
```
|
|
|
|
nmake /S
|
|
|
|
```
|
|
|
|
|
|
On Unix make you can mostly override verbose mode by using
|
|
On Unix make you can mostly override verbose mode by using
|
|
|
|
```shell
|
|
make VERBOSE=""
|
|
make VERBOSE=""
|
|
|
|
```
|
|
|
|
|
|
If you are on Windows using Borland or NMake Makefiles, you will see
|
|
If you are on Windows using Borland or NMake Makefiles, you will see
|
|
lines like:
|
|
lines like:
|
|
|
|
```
|
|
cl @c:\DOCUME~1\ANDY~1.KIT\LOCALS~1\Temp\nma03504
|
|
cl @c:\DOCUME~1\ANDY~1.KIT\LOCALS~1\Temp\nma03504
|
|
|
|
```
|
|
|
|
|
|
The reason for this is that Borland and Microsoft Visual Studio make
|
|
The reason for this is that Borland and Microsoft Visual Studio make
|
|
programs have limitation on the length of command strings. They overcome
|
|
programs have limitation on the length of command strings. They overcome
|
... | @@ -202,12 +205,11 @@ this limitation by writing arguments to the file and then pass file to |
... | @@ -202,12 +205,11 @@ this limitation by writing arguments to the file and then pass file to |
|
the program.
|
|
the program.
|
|
|
|
|
|
If you actually want to see what the command looks like, set
|
|
If you actually want to see what the command looks like, set
|
|
CMAKE_START_TEMP_FILE and CMAKE_END_TEMP_FILE to "" -- be warned,
|
|
`CMAKE_START_TEMP_FILE` and `CMAKE_END_TEMP_FILE` to `""` -- be warned,
|
|
however, you cannot set these as variables on the CMake command line
|
|
however, you cannot set these as variables on the CMake command line
|
|
with -D. Instead, see the very bottom of the file
|
|
with `-D`. Instead, see the very bottom of the file
|
|
"Modules/Platform/Windows.cmake" and uncomment the lines that set these
|
|
`Modules/Platform/Windows.cmake` and uncomment the lines that set these
|
|
variables to the empty
|
|
variables to the empty string.
|
|
string.
|
|
|
|
|
|
|
|
### Is there a way to skip checking of dependent libraries when compiling?
|
|
### Is there a way to skip checking of dependent libraries when compiling?
|
|
|
|
|
... | @@ -215,22 +217,23 @@ string. |
... | @@ -215,22 +217,23 @@ string. |
|
|
|
|
|
When using the Makefile generator under \*nix you can append "/fast" to
|
|
When using the Makefile generator under \*nix you can append "/fast" to
|
|
your target name. For example:
|
|
your target name. For example:
|
|
|
|
```shell
|
|
make target_name/fast
|
|
make target_name/fast
|
|
|
|
```
|
|
|
|
|
|
Under Windows use a backslash instead:
|
|
Under Windows use a backslash instead:
|
|
|
|
```
|
|
make target_name\fast
|
|
make target_name\fast
|
|
|
|
```
|
|
|
|
|
|
Be aware that this can cause link errors if the targets that were
|
|
Be aware that this can cause link errors if the targets that were
|
|
skipped are not actually built. Use it only if you know what you're
|
|
skipped are not actually built. Use it only if you know what you're
|
|
doing\!
|
|
doing!
|
|
|
|
|
|
**Using Visual Studio \>= 7.1**
|
|
**Using Visual Studio \>= 7.1**
|
|
|
|
|
|
If you have Visual Studio .NET 7.1 or greater you can use the native
|
|
If you have Visual Studio .NET 7.1 or greater you can use the native
|
|
option to right click on a project and choose to build just that
|
|
option to right click on a project and choose to build just that project.
|
|
project.
|
|
|
|
|
|
|
|
**Using Visual Studio \<= 7.0**
|
|
**Using Visual Studio \<= 7.0**
|
|
|
|
|
... | @@ -240,8 +243,7 @@ however you can take advantage of CTRL+F7 to manually compile a source |
... | @@ -240,8 +243,7 @@ however you can take advantage of CTRL+F7 to manually compile a source |
|
file for the affected target and then relink the target by right
|
|
file for the affected target and then relink the target by right
|
|
clicking on it and choosing Link. You'll have to ensure that all
|
|
clicking on it and choosing Link. You'll have to ensure that all
|
|
dependent libraries are made up-to-date however or suffer through
|
|
dependent libraries are made up-to-date however or suffer through
|
|
Visual's slow
|
|
Visual's slow check.
|
|
check.
|
|
|
|
|
|
|
|
### I set a cmake variable in my environment, but it didn't change anything. Why?
|
|
### I set a cmake variable in my environment, but it didn't change anything. Why?
|
|
|
|
|
... | @@ -261,34 +263,35 @@ For C and C++, set the `CC` and `CXX` environment variables. This method |
... | @@ -261,34 +263,35 @@ For C and C++, set the `CC` and `CXX` environment variables. This method |
|
is not guaranteed to work for all generators. (Specifically, if you are
|
|
is not guaranteed to work for all generators. (Specifically, if you are
|
|
trying to set Xcode's `GCC_VERSION`, this method confuses Xcode.)
|
|
trying to set Xcode's `GCC_VERSION`, this method confuses Xcode.)
|
|
|
|
|
|
For
|
|
For example:
|
|
example:
|
|
```shell
|
|
|
|
CC=gcc-4.2 CXX=/usr/bin/g++-4.2 cmake -G "Your Generator" path/to/your/source
|
|
CC=gcc-4.2 CXX=/usr/bin/g++-4.2 cmake -G "Your Generator" path/to/your/source
|
|
```
|
|
|
|
|
|
#### Method 2: use cmake -D
|
|
#### Method 2: use cmake -D
|
|
|
|
|
|
Set the appropriate `CMAKE_FOO_COMPILER` variable(s) to a valid compiler
|
|
Set the appropriate `CMAKE_FOO_COMPILER` variable(s) to a valid compiler
|
|
name or full path on the command-line using `cmake -D`.
|
|
name or full path on the command-line using `cmake -D`.
|
|
|
|
|
|
For
|
|
For example:
|
|
example:
|
|
```shell
|
|
|
|
cmake -G "Your Generator" -D CMAKE_C_COMPILER=gcc-4.2 -D CMAKE_CXX_COMPILER=g++-4.2 path/to/your/source
|
|
cmake -G "Your Generator" -D CMAKE_C_COMPILER=gcc-4.2 -D CMAKE_CXX_COMPILER=g++-4.2 path/to/your/source
|
|
```
|
|
|
|
|
|
#### Method 3 (avoid): use set()
|
|
#### Method 3 (avoid): use set()
|
|
|
|
|
|
Set the appropriate `CMAKE_FOO_COMPILER` variable(s) to a valid compiler
|
|
Set the appropriate `CMAKE_FOO_COMPILER` variable(s) to a valid compiler
|
|
name or full path in a list file using `set()`. This must be done
|
|
name or full path in a list file using `set()`. This must be done
|
|
*before* any language is set (ie before any `project()` or
|
|
*before* any language is set(ie before any `project()` or
|
|
`enable_language()` command).
|
|
`enable_language()` command).
|
|
|
|
|
|
For example:
|
|
For example:
|
|
|
|
```cmake
|
|
|
|
set(CMAKE_C_COMPILER "gcc-4.2")
|
|
|
|
set(CMAKE_CXX_COMPILER "/usr/bin/g++-4.2")
|
|
|
|
|
|
set(CMAKE_C_COMPILER "gcc-4.2")
|
|
project("YourProjectName")
|
|
set(CMAKE_CXX_COMPILER "/usr/bin/g++-4.2")
|
|
```
|
|
|
|
|
|
project("YourProjectName")
|
|
|
|
|
|
|
|
### I change CMAKE_C_COMPILER in the GUI but it changes back on the next configure step. Why?
|
|
### I change CMAKE_C_COMPILER in the GUI but it changes back on the next configure step. Why?
|
|
|
|
|
... | @@ -304,12 +307,13 @@ some existing path. If that is possible, it will do it. If not, it will |
... | @@ -304,12 +307,13 @@ some existing path. If that is possible, it will do it. If not, it will |
|
not do anything.
|
|
not do anything.
|
|
|
|
|
|
For example:
|
|
For example:
|
|
|
|
```
|
|
/usr/loc<TAB>
|
|
/usr/loc<TAB>
|
|
|
|
```
|
|
will expand to
|
|
will expand to
|
|
|
|
```
|
|
/usr/local/
|
|
/usr/local/
|
|
|
|
```
|
|
|
|
|
|
## Out-of-source build trees
|
|
## Out-of-source build trees
|
|
|
|
|
... | @@ -322,18 +326,22 @@ a completely separate directory, so that your source tree is unchanged. |
... | @@ -322,18 +326,22 @@ a completely separate directory, so that your source tree is unchanged. |
|
In the first example, an in-place build is performed, i.e., the binaries
|
|
In the first example, an in-place build is performed, i.e., the binaries
|
|
are placed in the same directory as the source code.
|
|
are placed in the same directory as the source code.
|
|
|
|
|
|
cd Hello
|
|
```shell
|
|
ccmake .
|
|
cd Hello
|
|
make
|
|
ccmake .
|
|
|
|
make
|
|
|
|
```
|
|
|
|
|
|
In the second example, an out-of-place build is performed, i.e., the
|
|
In the second example, an out-of-place build is performed, i.e., the
|
|
source code, libraries, and executables are produced in a directory
|
|
source code, libraries, and executables are produced in a directory
|
|
separate from the source code directory(ies).
|
|
separate from the source code directory(ies).
|
|
|
|
|
|
mkdir HelloBuild
|
|
```shell
|
|
cd HelloBuild
|
|
mkdir HelloBuild
|
|
ccmake ../Hello
|
|
cd HelloBuild
|
|
make
|
|
ccmake ../Hello
|
|
|
|
make
|
|
|
|
```
|
|
|
|
|
|
Out-of-source builds are recommended, as you can build multiple variants
|
|
Out-of-source builds are recommended, as you can build multiple variants
|
|
in separate directories, e.g., HelloBuildDebug, HelloBuildRelease.
|
|
in separate directories, e.g., HelloBuildDebug, HelloBuildRelease.
|
... | @@ -348,11 +356,11 @@ CMakeCache.txt. |
... | @@ -348,11 +356,11 @@ CMakeCache.txt. |
|
This means that there is a CMakeCache.txt file in the source tree,
|
|
This means that there is a CMakeCache.txt file in the source tree,
|
|
possibly as part of an existing in-source build. If CMake is given the
|
|
possibly as part of an existing in-source build. If CMake is given the
|
|
path to a directory with a CMakeCache.txt file, it assumes the directory
|
|
path to a directory with a CMakeCache.txt file, it assumes the directory
|
|
is a build tree. Therefore if one runs "cmake ../mysrc" to build
|
|
is a build tree. Therefore if one runs `cmake ../mysrc` to build
|
|
out-of-source but there is a mysrc/CMakeCache.txt file then cmake will
|
|
out-of-source but there is a mysrc/CMakeCache.txt file then cmake will
|
|
treat mysrc as the build tree.
|
|
treat mysrc as the build tree.
|
|
|
|
|
|
This is a side-effect of the feature that allows "cmake ." to be used to
|
|
This is a side-effect of the feature that allows `cmake .` to be used to
|
|
regenerate a build tree. The behavior will not be changed because mixing
|
|
regenerate a build tree. The behavior will not be changed because mixing
|
|
in-source and out-of-source builds is not safe anyway (configured
|
|
in-source and out-of-source builds is not safe anyway (configured
|
|
headers may be found in the wrong place).
|
|
headers may be found in the wrong place).
|
... | @@ -386,17 +394,17 @@ the old one. |
... | @@ -386,17 +394,17 @@ the old one. |
|
|
|
|
|
### CMake does not generate a "make distclean" target. Why?
|
|
### CMake does not generate a "make distclean" target. Why?
|
|
|
|
|
|
Some build trees created with GNU autotools have a "make distclean"
|
|
Some build trees created with GNU autotools have a `make distclean`
|
|
target that cleans the build and also removes Makefiles and other parts
|
|
target that cleans the build and also removes Makefiles and other parts
|
|
of the generated build system. CMake does not generate a "make
|
|
of the generated build system. CMake does not generate a `make distclean`
|
|
distclean" target because CMakeLists.txt files can run scripts and
|
|
target because CMakeLists.txt files can run scripts and
|
|
arbitrary commands; CMake has no way of tracking exactly which files are
|
|
arbitrary commands; CMake has no way of tracking exactly which files are
|
|
generated as part of running CMake. Providing a distclean target would
|
|
generated as part of running CMake. Providing a distclean target would
|
|
give users the false impression that it would work as expected. (CMake
|
|
give users the false impression that it would work as expected. (CMake
|
|
does generate a "make clean" target to remove files generated by the
|
|
does generate a `make clean` target to remove files generated by the
|
|
compiler and linker.)
|
|
compiler and linker.)
|
|
|
|
|
|
A "make distclean" target is only necessary if the user performs an
|
|
A `make distclean` target is only necessary if the user performs an
|
|
in-source build. CMake supports in-source builds, but we strongly
|
|
in-source build. CMake supports in-source builds, but we strongly
|
|
encourage users to adopt the notion of an out-of-source build. Using a
|
|
encourage users to adopt the notion of an out-of-source build. Using a
|
|
build tree that is separate from the source tree will prevent CMake from
|
|
build tree that is separate from the source tree will prevent CMake from
|
... | @@ -405,9 +413,9 @@ the source tree, there is no need for a distclean target. One can start |
... | @@ -405,9 +413,9 @@ the source tree, there is no need for a distclean target. One can start |
|
a fresh build by deleting the build tree or creating a separate build
|
|
a fresh build by deleting the build tree or creating a separate build
|
|
tree.
|
|
tree.
|
|
|
|
|
|
(If a CMakeLists.txt uses ADD_CUSTOM_COMMAND to generate source files
|
|
(If a CMakeLists.txt uses `add_custom_command` to generate source files
|
|
in the source tree, not the build tree, then in CMake 2.2 or higher
|
|
in the source tree, not the build tree, then in CMake 2.2 or higher
|
|
"make clean" will remove them. See next question.)
|
|
`make clean` will remove them. See next question.)
|
|
|
|
|
|
### Running "make clean" does not remove custom command outputs. Why?
|
|
### Running "make clean" does not remove custom command outputs. Why?
|
|
|
|
|
... | @@ -415,12 +423,12 @@ In CMake 2.2 and higher custom command outputs should be removed by make |
... | @@ -415,12 +423,12 @@ In CMake 2.2 and higher custom command outputs should be removed by make |
|
clean. Make sure you are using at least this version. Prior to CMake 2.2
|
|
clean. Make sure you are using at least this version. Prior to CMake 2.2
|
|
custom command outputs were not automatically added to the list of files
|
|
custom command outputs were not automatically added to the list of files
|
|
to clean. In CMake 2.0 the developer can specify a list of files to be
|
|
to clean. In CMake 2.0 the developer can specify a list of files to be
|
|
deleted. This can be done using SET_DIRECTORY_PROPERTIES setting
|
|
deleted. This can be done using `set_directory_properties` setting
|
|
property ADDITIONAL_MAKE_CLEAN_FILES to the list of files.
|
|
property `ADDITIONAL_MAKE_CLEAN_FILES` to the list of files.
|
|
|
|
|
|
We however strongly recommend using an "out-of-source" build which never
|
|
We however strongly recommend using an "out-of-source" build which never
|
|
writes any files to the source tree. Using a separate source and build
|
|
writes any files to the source tree. Using a separate source and build
|
|
tree greatly reduces the need for "make clean" and "make distclean"
|
|
tree greatly reduces the need for `make clean` and `make distclean`
|
|
targets to clean away files that differ between builds.
|
|
targets to clean away files that differ between builds.
|
|
|
|
|
|
## Writing CMakeLists.txt
|
|
## Writing CMakeLists.txt
|
... | @@ -430,9 +438,9 @@ targets to clean away files that differ between builds. |
... | @@ -430,9 +438,9 @@ targets to clean away files that differ between builds. |
|
As of CMake 2.6 we employ a "Policy" mechanism to provide backwards
|
|
As of CMake 2.6 we employ a "Policy" mechanism to provide backwards
|
|
compatibility. The basic requirement for projects is to include one line
|
|
compatibility. The basic requirement for projects is to include one line
|
|
at the top of the highest CMakeLists.txt file:
|
|
at the top of the highest CMakeLists.txt file:
|
|
|
|
```cmake
|
|
cmake_minimum_required(VERSION 2.6) # or other version
|
|
cmake_minimum_required(VERSION 2.6) # or other version
|
|
|
|
```
|
|
This tells versions of CMake older than that specified that they are too
|
|
This tells versions of CMake older than that specified that they are too
|
|
old to build the project. They will report this information to the user.
|
|
old to build the project. They will report this information to the user.
|
|
It also tells versions of CMake newer than that specified that the
|
|
It also tells versions of CMake newer than that specified that the
|
... | @@ -447,10 +455,9 @@ enables additional compatibility. For futher documentation, see |
... | @@ -447,10 +455,9 @@ enables additional compatibility. For futher documentation, see |
|
|
|
|
|
### How do I get the current source or binary directory?
|
|
### How do I get the current source or binary directory?
|
|
|
|
|
|
The variable CMAKE_CURRENT_SOURCE_DIR contains the absolute path to
|
|
The variable `CMAKE_CURRENT_SOURCE_DIR` contains the absolute path to
|
|
your current source directory, while CMAKE_CURRENT_BINARY_DIR points
|
|
your current source directory, while `CMAKE_CURRENT_BINARY_DIR` points
|
|
to the equivalent binary
|
|
to the equivalent binary directory.
|
|
directory.
|
|
|
|
|
|
|
|
### Why are my CMake variables not updated in the GUI after a SET command?
|
|
### Why are my CMake variables not updated in the GUI after a SET command?
|
|
|
|
|
... | @@ -459,91 +466,94 @@ used to initialize the values seen by the code in CMakeLists.txt files. |
... | @@ -459,91 +466,94 @@ used to initialize the values seen by the code in CMakeLists.txt files. |
|
|
|
|
|
Changes made by the code are used during the configure step and seen by
|
|
Changes made by the code are used during the configure step and seen by
|
|
the generators but are not stored back into the cache. For example:
|
|
the generators but are not stored back into the cache. For example:
|
|
|
|
```cmake
|
|
SET(BUILD_SHARED_LIBS ON)
|
|
set(BUILD_SHARED_LIBS ON)
|
|
|
|
```
|
|
will turn on building of shared libraries for the directory containing
|
|
will turn on building of shared libraries for the directory containing
|
|
the command and all subdirectories, but the change will not appear in
|
|
the command and all subdirectories, but the change will not appear in
|
|
the GUI.
|
|
the GUI.
|
|
|
|
|
|
You can use the CACHE and FORCE options on the SET command to change
|
|
You can use the CACHE and FORCE options on the `set` command to change
|
|
variables in a way that will be reflected in the GUI. Run
|
|
variables in a way that will be reflected in the GUI. Run
|
|
|
|
```shell
|
|
cmake --help-command SET
|
|
cmake --help-command set
|
|
|
|
```
|
|
to see full instructions for the
|
|
to see full instructions for the command.
|
|
command.
|
|
|
|
|
|
|
|
### How can I change the default build mode and see it reflected in the GUI?
|
|
### How can I change the default build mode and see it reflected in the GUI?
|
|
|
|
|
|
Adapt the following commands in your CMakeLists.txt (this example sets
|
|
Adapt the following commands in your CMakeLists.txt (this example sets
|
|
the Release With Debug Information mode):
|
|
the Release With Debug Information mode):
|
|
|
|
```cmake
|
|
IF(NOT CMAKE_BUILD_TYPE)
|
|
if(NOT CMAKE_BUILD_TYPE)
|
|
SET(CMAKE_BUILD_TYPE RelWithDebInfo CACHE STRING
|
|
set(CMAKE_BUILD_TYPE RelWithDebInfo CACHE STRING
|
|
"Choose the type of build, options are: None Debug Release RelWithDebInfo MinSizeRel."
|
|
"Choose the type of build, options are: None Debug Release RelWithDebInfo MinSizeRel."
|
|
FORCE)
|
|
FORCE)
|
|
ENDIF(NOT CMAKE_BUILD_TYPE)
|
|
endif()
|
|
|
|
```
|
|
|
|
|
|
### How do I generate an executable, then use the executable to generate a file?
|
|
### How do I generate an executable, then use the executable to generate a file?
|
|
|
|
|
|
Create the generator executable by just adding a target:
|
|
Create the generator executable by just adding a target:
|
|
|
|
```cmake
|
|
ADD_EXECUTABLE(generate generate.c)
|
|
add_executable(generate generate.c)
|
|
|
|
```
|
|
|
|
|
|
The rest of the process is simpler in CMake 2.6 and above than in
|
|
The rest of the process is simpler in CMake 2.6 and above than in
|
|
previous versions.
|
|
previous versions.
|
|
|
|
|
|
Use `ADD_CUSTOM_COMMAND` to specify a custom build rule for the file.
|
|
Use `add_custom_command` to specify a custom build rule for the file.
|
|
(In this example we assume `generate` accepts the input and output files
|
|
(In this example we assume `generate` accepts the input and output files
|
|
as arguments.)
|
|
as arguments.)
|
|
|
|
```cmake
|
|
ADD_CUSTOM_COMMAND(
|
|
add_custom_command(
|
|
OUTPUT someoutput.txt
|
|
OUTPUT someoutput.txt
|
|
COMMAND generate ${CMAKE_CURRENT_SOURCE_DIR}/someinput.txt ${CMAKE_CURRENT_BINARY_DIR}/someoutput.txt
|
|
COMMAND generate ${CMAKE_CURRENT_SOURCE_DIR}/someinput.txt ${CMAKE_CURRENT_BINARY_DIR}/someoutput.txt
|
|
DEPENDS generate ${CMAKE_CURRENT_SOURCE_DIR}/someinput.txt
|
|
DEPENDS generate ${CMAKE_CURRENT_SOURCE_DIR}/someinput.txt
|
|
)
|
|
)
|
|
|
|
```
|
|
|
|
|
|
This tells CMake how to build the file but does not actually add a rule
|
|
This tells CMake how to build the file but does not actually add a rule
|
|
to the build system. Another target must require it. One may create a
|
|
to the build system. Another target must require it. One may create a
|
|
custom target explicitly for this rule:
|
|
custom target explicitly for this rule:
|
|
|
|
```cmake
|
|
ADD_CUSTOM_TARGET(driver ALL DEPENDS someoutput.txt)
|
|
add_custom_target(driver ALL DEPENDS someoutput.txt)
|
|
|
|
```
|
|
or the file may be added as part of some other target:
|
|
or the file may be added as part of some other target:
|
|
|
|
```cmake
|
|
|
|
add_executable(product product.c someoutput.txt)
|
|
|
|
```
|
|
|
|
|
|
ADD_EXECUTABLE(product product.c someoutput.txt)
|
|
In CMake 2.4 and below the `generate` target may
|
|
|
|
|
|
<font color=#555555> In CMake 2.4 and below the `generate` target may
|
|
|
|
not be specified directly in the `COMMAND` option of
|
|
not be specified directly in the `COMMAND` option of
|
|
`add_custom_command` (but it can still be used in the `DEPENDS` option
|
|
`add_custom_command` (but it can still be used in the `DEPENDS` option
|
|
as of CMake 2.4). Instead use GET_TARGET_PROPERTY to obtain the
|
|
as of CMake 2.4). Instead use `get_target_property` to obtain the
|
|
location of the generated executable. Additionally, the output must
|
|
location of the generated executable. Additionally, the output must
|
|
always be specified by full path.
|
|
always be specified by full path.
|
|
|
|
```cmake
|
|
GET_TARGET_PROPERTY(GENERATE_EXE generate LOCATION)
|
|
get_target_property(GENERATE_EXE generate LOCATION)
|
|
ADD_CUSTOM_COMMAND(
|
|
add_custom_command(
|
|
OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/someoutput.txt
|
|
OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/someoutput.txt
|
|
COMMAND ${GENERATE_EXE} ${CMAKE_CURRENT_SOURCE_DIR}/someinput.txt ${CMAKE_CURRENT_BINARY_DIR}/someoutput.txt
|
|
COMMAND ${GENERATE_EXE} ${CMAKE_CURRENT_SOURCE_DIR}/someinput.txt ${CMAKE_CURRENT_BINARY_DIR}/someoutput.txt
|
|
DEPENDS generate
|
|
DEPENDS generate
|
|
)
|
|
)
|
|
|
|
```
|
|
</font>
|
|
|
|
|
|
|
|
### How can I generate a source file during the build?
|
|
### How can I generate a source file during the build?
|
|
|
|
|
|
The ADD_CUSTOM_COMMAND command lets you generate a source file that
|
|
The `add_custom_command` command lets you generate a source file that
|
|
you can then include in another target. For example:
|
|
you can then include in another target. For example:
|
|
|
|
```cmake
|
|
|
|
add_custom_command(
|
|
|
|
OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/foo.c
|
|
|
|
COMMAND ${CMAKE_COMMAND} -E copy ${CMAKE_CURRENT_SOURCE_DIR}/bar.c ${CMAKE_CURRENT_BINARY_DIR}/foo.c
|
|
|
|
DEPENDS ${CMAKE_CURRENT_SOURCE_DIR}/bar.c
|
|
|
|
)
|
|
|
|
add_executable(foo foo.c)
|
|
|
|
```
|
|
|
|
|
|
ADD_CUSTOM_COMMAND(
|
|
This will create an executable by copying "bar.c" to "foo.c" and then
|
|
OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/foo.c
|
|
compiling "foo.c" to produce "foo". CMake allows you to put generated source
|
|
COMMAND ${CMAKE_COMMAND} -E copy ${CMAKE_CURRENT_SOURCE_DIR}/bar.c ${CMAKE_CURRENT_BINARY_DIR}/foo.c
|
|
|
|
DEPENDS ${CMAKE_CURRENT_SOURCE_DIR}/bar.c
|
|
|
|
)
|
|
|
|
ADD_EXECUTABLE(foo foo.c)
|
|
|
|
|
|
|
|
This will create an executable by copying bar.c to foo.c and then
|
|
|
|
compiling foo.c to produce foo. CMake allows you to put generated source
|
|
|
|
files in the current source or binary directory, so we were careful to
|
|
files in the current source or binary directory, so we were careful to
|
|
output foo.c to the current binary directory. When we add foo.c to foo,
|
|
output foo.c to the current binary directory. When we add foo.c to foo,
|
|
CMake will look in either directory for it. Even if foo.c does not yet
|
|
CMake will look in either directory for it. Even if foo.c does not yet
|
... | @@ -551,7 +561,7 @@ exist, CMake is smart enough to notice that a custom command creates it. |
... | @@ -551,7 +561,7 @@ exist, CMake is smart enough to notice that a custom command creates it. |
|
(For the file named as the OUTPUT, CMake has its GENERATED source file
|
|
(For the file named as the OUTPUT, CMake has its GENERATED source file
|
|
property set to true.)
|
|
property set to true.)
|
|
|
|
|
|
You can also use ADD_CUSTOM_COMMAND when the [generator command is
|
|
You can also use `add_custom_command` when the [generator command is
|
|
another executable in the same
|
|
another executable in the same
|
|
project](FAQ#how-do-i-generate-an-executable-then-use-the-executable-to-generate-a-file "wikilink").
|
|
project](FAQ#how-do-i-generate-an-executable-then-use-the-executable-to-generate-a-file "wikilink").
|
|
|
|
|
... | @@ -562,75 +572,78 @@ example, suppose you had a program that read input.txt and generated |
... | @@ -562,75 +572,78 @@ example, suppose you had a program that read input.txt and generated |
|
three files output1.cpp, output2.h, and output3.cpp, and that those
|
|
three files output1.cpp, output2.h, and output3.cpp, and that those
|
|
three files needed to be compiled into an executable program. The cmake
|
|
three files needed to be compiled into an executable program. The cmake
|
|
list file for that would look like this:
|
|
list file for that would look like this:
|
|
|
|
```cmake
|
|
PROJECT(FOO)
|
|
project(FOO)
|
|
# make sure cmake addes the binary directory for the project to the include path
|
|
# make sure cmake addes the binary directory for the project to the include path
|
|
INCLUDE_DIRECTORIES(${FOO_BINARY_DIR})
|
|
include_directories(${FOO_BINARY_DIR})
|
|
# add the executable that will do the generation
|
|
# add the executable that will do the generation
|
|
ADD_EXECUTABLE(my_generator my_generator.cxx)
|
|
add_executable(my_generator my_generator.cxx)
|
|
GET_TARGET_PROPERTY(MY_GENERATOR_EXE my_generator LOCATION)
|
|
get_target_property(MY_GENERATOR_EXE my_generator LOCATION)
|
|
# add the custom command that will generate all three files
|
|
# add the custom command that will generate all three files
|
|
ADD_CUSTOM_COMMAND(
|
|
add_custom_command(
|
|
OUTPUT ${FOO_BINARY_DIR}/output1.cpp ${FOO_BINARY_DIR}/output2.h ${FOO_BINARY_DIR}/output3.cpp
|
|
OUTPUT ${FOO_BINARY_DIR}/output1.cpp ${FOO_BINARY_DIR}/output2.h ${FOO_BINARY_DIR}/output3.cpp
|
|
COMMAND ${MY_GENERATOR_EXE} ${FOO_BINARY_DIR} ${FOO_SOURCE_DIR}/input.txt
|
|
COMMAND ${MY_GENERATOR_EXE} ${FOO_BINARY_DIR} ${FOO_SOURCE_DIR}/input.txt
|
|
DEPENDS my_generator
|
|
DEPENDS my_generator
|
|
MAIN_DEPENDENCY ${FOO_SOURCE_DIR}/input.txt
|
|
MAIN_DEPENDENCY ${FOO_SOURCE_DIR}/input.txt
|
|
)
|
|
)
|
|
# now create an executable using the generated files
|
|
# now create an executable using the generated files
|
|
ADD_EXECUTABLE(generated
|
|
add_executable(generated
|
|
${FOO_BINARY_DIR}/output1.cpp
|
|
${FOO_BINARY_DIR}/output1.cpp
|
|
${FOO_BINARY_DIR}/output2.h
|
|
${FOO_BINARY_DIR}/output2.h
|
|
${FOO_BINARY_DIR}/output3.cpp)
|
|
${FOO_BINARY_DIR}/output3.cpp)
|
|
|
|
```
|
|
|
|
|
|
CMake 2.4 allows you to generate a header file. Because generated
|
|
CMake 2.4 allows you to generate a header file. Because generated
|
|
headers often cause unnecessary rebuilds, you should try to avoid them;
|
|
headers often cause unnecessary rebuilds, you should try to avoid them;
|
|
consider using the CONFIGURE_FILE command to prepare the header at
|
|
consider using the `configure_file` command to prepare the header at
|
|
CMake time. If you must generate a header file, use code like this:
|
|
CMake time. If you must generate a header file, use code like this:
|
|
|
|
```cmake
|
|
ADD_CUSTOM_COMMAND(
|
|
add_custom_command(
|
|
OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/foo.h
|
|
OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/foo.h
|
|
COMMAND ${CMAKE_COMMAND} -E copy ${CMAKE_CURRENT_SOURCE_DIR}/bar.h ${CMAKE_CURRENT_BINARY_DIR}/foo.h
|
|
COMMAND ${CMAKE_COMMAND} -E copy ${CMAKE_CURRENT_SOURCE_DIR}/bar.h ${CMAKE_CURRENT_BINARY_DIR}/foo.h
|
|
DEPENDS ${CMAKE_CURRENT_SOURCE_DIR}/bar.h
|
|
DEPENDS ${CMAKE_CURRENT_SOURCE_DIR}/bar.h
|
|
)
|
|
)
|
|
ADD_EXECUTABLE(foo foo.c ${CMAKE_CURRENT_BINARY_DIR}/foo.h)
|
|
add_executable(foo foo.c ${CMAKE_CURRENT_BINARY_DIR}/foo.h)
|
|
|
|
```
|
|
|
|
|
|
This is like the first example above, except that it generates a header
|
|
This is like the first example above, except that it generates a header
|
|
instead of a C file. The header might not exist when the build system
|
|
instead of a C file. The header might not exist when the build system
|
|
scans foo.c's dependencies, so there is no way for CMake to know that
|
|
scans dependencies for "foo.c", so there is no way for CMake to know that
|
|
this target requires foo.h unless we can tell it that foo.h may exist in
|
|
this target requires "foo.h" unless we can tell it that "foo.h" may exist in
|
|
the future. We give CMake this knowledge by listing the generated header
|
|
the future. We give CMake this knowledge by listing the generated header
|
|
file in the set of source files for the target. (This requires CMake
|
|
file in the set of source files for the target. (This requires CMake
|
|
2.4. Previous versions of CMake required use of the OBJECT_DEPENDS
|
|
2.4. Previous versions of CMake required use of the `OBJECT_DEPENDS`
|
|
source file
|
|
source file property.)
|
|
property.)
|
|
|
|
|
|
|
|
### How can I add a dependency to a source file which is generated in a subdirectory?
|
|
### How can I add a dependency to a source file which is generated in a subdirectory?
|
|
|
|
|
|
Rules created with `ADD_CUSTOM_COMMAND` as
|
|
Rules created with `add_custom_command` as
|
|
[above](FAQ#how-can-i-generate-a-source-file-during-the-build "wikilink")
|
|
[above](FAQ#how-can-i-generate-a-source-file-during-the-build "wikilink")
|
|
have scope only in the directory in which they are specified. If the
|
|
have scope only in the directory in which they are specified. If the
|
|
generated file is needed in another directory, a target-level dependency
|
|
generated file is needed in another directory, a target-level dependency
|
|
needs to be added. Create a target in the subdirectory with the custom
|
|
needs to be added. Create a target in the subdirectory with the custom
|
|
rule in order to drive it:
|
|
rule in order to drive it:
|
|
|
|
|
|
# subdir/CMakeLists.txt
|
|
```cmake
|
|
ADD_CUSTOM_COMMAND(
|
|
# subdir/CMakeLists.txt
|
|
OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/foo.c
|
|
add_custom_command(
|
|
COMMAND ${CMAKE_COMMAND} copy ${CMAKE_CURRENT_SOURCE_DIR}/bar.c ${CMAKE_CURRENT_BINARY_DIR}/foo.c
|
|
OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/foo.c
|
|
DEPENDS ${CMAKE_CURRENT_SOURCE_DIR}/bar.c
|
|
COMMAND ${CMAKE_COMMAND} copy ${CMAKE_CURRENT_SOURCE_DIR}/bar.c ${CMAKE_CURRENT_BINARY_DIR}/foo.c
|
|
)
|
|
DEPENDS ${CMAKE_CURRENT_SOURCE_DIR}/bar.c
|
|
ADD_CUSTOM_TARGET(generate_foo DEPENDS ${CMAKE_CURRENT_BINARY_DIR}/foo.c)
|
|
)
|
|
|
|
add_custom_target(generate_foo DEPENDS ${CMAKE_CURRENT_BINARY_DIR}/foo.c)
|
|
|
|
```
|
|
Now other targets can depend on the target from the subdirectory:
|
|
Now other targets can depend on the target from the subdirectory:
|
|
|
|
```cmake
|
|
# CMakeLists.txt
|
|
# CMakeLists.txt
|
|
ADD_SUBDIRECTORY(subdir)
|
|
add_subdirectory(subdir)
|
|
# Create the executable.
|
|
# Create the executable.
|
|
ADD_EXECUTABLE(generated ${CMAKE_CURRENT_BINARY_DIR}/subdir/foo.c)
|
|
add_executable(generated ${CMAKE_CURRENT_BINARY_DIR}/subdir/foo.c)
|
|
# Tell CMake the source won't be available until build time.
|
|
# Tell CMake the source won't be available until build time.
|
|
SET_SOURCE_FILES_PROPERTIES(${CMAKE_CURRENT_BINARY_DIR}/subdir/foo.c PROPERTIES GENERATED 1)
|
|
set_source_file_properties(${CMAKE_CURRENT_BINARY_DIR}/subdir/foo.c PROPERTIES GENERATED 1)
|
|
# Make sure the source is generated before the executable builds.
|
|
# Make sure the source is generated before the executable builds.
|
|
ADD_DEPENDENCIES(generated generate_foo)
|
|
add_dependencies(generated generate_foo)
|
|
|
|
```
|
|
|
|
|
|
### How can I generate a file used in more than one target in the same directory?
|
|
### How can I generate a file used in more than one target in the same directory?
|
|
|
|
|
... | @@ -640,62 +653,67 @@ There is no other place to put it. If a single custom command output is |
... | @@ -640,62 +653,67 @@ There is no other place to put it. If a single custom command output is |
|
listed in more than one target and the targets have no dependency
|
|
listed in more than one target and the targets have no dependency
|
|
relationship they will race to run the custom command during a parallel
|
|
relationship they will race to run the custom command during a parallel
|
|
build and possibly clobber each other. For example:
|
|
build and possibly clobber each other. For example:
|
|
|
|
```cmake
|
|
add_custom_command(OUTPUT Foo.c COMMAND ... DEPENDS ...)
|
|
add_custom_command(OUTPUT Foo.c COMMAND ... DEPENDS ...)
|
|
add_library(FooStatic STATIC Foo.c)
|
|
add_library(FooStatic STATIC Foo.c)
|
|
add_library(FooShared SHARED Foo.c)
|
|
add_library(FooShared SHARED Foo.c)
|
|
|
|
```
|
|
|
|
|
|
There are at least two solutions to this problem. First, one may use
|
|
There are at least two solutions to this problem. First, one may use
|
|
add_dependencies to serialize the targets involved:
|
|
add_dependencies to serialize the targets involved:
|
|
|
|
```cmake
|
|
add_dependencies(FooShared FooStatic)
|
|
add_dependencies(FooShared FooStatic)
|
|
|
|
```
|
|
|
|
|
|
Second, one may add a custom target dedicated to generating files for
|
|
Second, one may add a custom target dedicated to generating files for
|
|
the other targets:
|
|
the other targets:
|
|
|
|
```cmake
|
|
add_custom_target(Foo DEPENDS Foo.c)
|
|
add_custom_target(Foo DEPENDS Foo.c)
|
|
add_dependencies(FooStatic Foo)
|
|
add_dependencies(FooStatic Foo)
|
|
add_dependencies(FooShared Foo)
|
|
add_dependencies(FooShared Foo)
|
|
|
|
```
|
|
|
|
|
|
The latter solution ensures that generated files are up to date before
|
|
The latter solution ensures that generated files are up to date before
|
|
any of the independent targets build so none of them will run the custom
|
|
any of the independent targets build so none of them will run the custom
|
|
command and there will be no
|
|
command and there will be no race.
|
|
race.
|
|
|
|
|
|
|
|
### I use EXEC_PROGRAM but the result is not set in subdirectories. Why?
|
|
### I use exec_program but the result is not set in subdirectories. Why?
|
|
|
|
|
|
An unfortunate holdover from ancient CMake versions is that certain
|
|
An unfortunate holdover from ancient CMake versions is that certain
|
|
commands are "inherited" into subdirectories and others are not.
|
|
commands are "inherited" into subdirectories and others are not.
|
|
EXEC_PROGRAM is not inherited. What this means is that when the
|
|
`exec_program` is not inherited. What this means is that when the
|
|
listfile code from a parent directory executes in a subdirectory the
|
|
listfile code from a parent directory executes in a subdirectory the
|
|
EXEC_PROGRAM command is left out. Therefore the code executes
|
|
`exec_program` command is left out. Therefore the code executes
|
|
differently. This problem was fixed in CMake 2.2, but for older versions
|
|
differently. This problem was fixed in CMake 2.2, but for older versions
|
|
you will have to cache the result:
|
|
you will have to cache the result:
|
|
|
|
```cmake
|
|
EXEC_PROGRAM(my-program OUTPUT_VARIABLE MY_OUTPUT)
|
|
exec_program(my-program OUTPUT_VARIABLE MY_OUTPUT)
|
|
SET(MY_OUTPUT "${MY_OUTPUT}" CACHE INTERNAL "")
|
|
set(MY_OUTPUT "${MY_OUTPUT}" CACHE INTERNAL "")
|
|
|
|
```
|
|
|
|
|
|
This will store the result in a global location so it will be available
|
|
This will store the result in a global location so it will be available
|
|
in the subdirectory. Be sure to choose a descriptive name for MY_OUTPUT
|
|
in the subdirectory. Be sure to choose a descriptive name for `MY_OUTPUT`
|
|
to avoid conflict in the global setting.
|
|
to avoid conflict in the global setting.
|
|
|
|
|
|
### How can I get or set environment variables?
|
|
### How can I get or set environment variables?
|
|
|
|
|
|
CMake names environment variables using an ENV prefix and surrounding
|
|
CMake names environment variables using an ENV prefix and surrounding
|
|
the names in curly braces. Here is an example:
|
|
the names in curly braces. Here is an example:
|
|
|
|
```cmake
|
|
MESSAGE("$ENV{PATH}")
|
|
message("$ENV{PATH}")
|
|
|
|
```
|
|
|
|
|
|
Reading variables will work in any version of CMake. Writing to them
|
|
Reading variables will work in any version of CMake. Writing to them
|
|
works in CMake 2.2 and higher using the following syntax:
|
|
works in CMake 2.2 and higher using the following syntax:
|
|
|
|
```cmake
|
|
SET(ENV{HELLO} "World")
|
|
set(ENV{HELLO} "World")
|
|
|
|
```
|
|
|
|
|
|
Note that there is currently no way to tell apart an empty environment
|
|
Note that there is currently no way to tell apart an empty environment
|
|
variable value from a variable that is not set at all.
|
|
variable value from a variable that is not set at all.
|
|
|
|
|
|
One should avoid using environment variables for controlling the flow of
|
|
One should avoid using environment variables for controlling the flow of
|
|
CMake code (such as in IF commands). The build system generated by CMake
|
|
CMake code (such as in `if` commands). The build system generated by CMake
|
|
may re-run CMake automatically when CMakeLists.txt files change. The
|
|
may re-run CMake automatically when CMakeLists.txt files change. The
|
|
environment in which this is executed is controlled by the build system
|
|
environment in which this is executed is controlled by the build system
|
|
and may not match that in which CMake was originally run. If you want to
|
|
and may not match that in which CMake was originally run. If you want to
|
... | @@ -704,7 +722,7 @@ variables set with the -D option. The settings will be saved in |
... | @@ -704,7 +722,7 @@ variables set with the -D option. The settings will be saved in |
|
CMakeCache.txt so that they don't have to be repeated every time CMake
|
|
CMakeCache.txt so that they don't have to be repeated every time CMake
|
|
is run on the same build tree.
|
|
is run on the same build tree.
|
|
|
|
|
|
Also, environment variables SET in the CMakeLists.txt *only* take effect
|
|
Also, environment variables `set` in the CMakeLists.txt *only* take effect
|
|
for cmake itself (*configure-time*), so you cannot use this method to
|
|
for cmake itself (*configure-time*), so you cannot use this method to
|
|
set an environment variable that a custom command might need
|
|
set an environment variable that a custom command might need
|
|
(*build-time*). Barring environment variable support by various CMake
|
|
(*build-time*). Barring environment variable support by various CMake
|
... | @@ -716,7 +734,7 @@ the commands to be executed. |
... | @@ -716,7 +734,7 @@ the commands to be executed. |
|
|
|
|
|
CMake has a list data type. A list is stored as a string of
|
|
CMake has a list data type. A list is stored as a string of
|
|
semicolon-separated list elements. Whitespace separated arguments to a
|
|
semicolon-separated list elements. Whitespace separated arguments to a
|
|
SET statement are interpreted as list elements. For instance,
|
|
`set` statement are interpreted as list elements. For instance,
|
|
|
|
|
|
```cmake
|
|
```cmake
|
|
set(var a b c d e)
|
|
set(var a b c d e)
|
... | @@ -736,51 +754,52 @@ See the [cmake-language(7)](https://cmake.org/cmake/help/latest/manual/cmake-lan |
... | @@ -736,51 +754,52 @@ See the [cmake-language(7)](https://cmake.org/cmake/help/latest/manual/cmake-lan |
|
|
|
|
|
### How can I get quoting and escapes to work properly?
|
|
### How can I get quoting and escapes to work properly?
|
|
|
|
|
|
If you want to escape a character in CMake, you use "\\", like in C
|
|
If you want to escape a character in CMake, you use `\`, like in C
|
|
code. For example, if you wanted to have a quote embedded in a string
|
|
code. For example, if you wanted to have a quote embedded in a string
|
|
you would do this: "\\"". However, each level of CMake that processes
|
|
you would do this: `\"`. However, each level of CMake that processes
|
|
your code will need one level of escaping to work. So, if you configure
|
|
your code will need one level of escaping to work. So, if you configure
|
|
a file that is read by cmake or cpack and you want to do the same thing,
|
|
a file that is read by cmake or cpack and you want to do the same thing,
|
|
you would do "\\\\\\"". You would still need to escape the " for the
|
|
you would do `\\\"`. You would still need to escape the `"` for the
|
|
first cmake that processes the string. However, this time, you would
|
|
first cmake that processes the string. However, this time, you would
|
|
want to also escape a '\\' as well. This would leave the next level of
|
|
want to also escape a `\` as well. This would leave the next level of
|
|
processing with "\\"". Also, for custom commands that may get passed to
|
|
processing with `\"`. Also, for custom commands that may get passed to
|
|
a shell, it maybe required to do escaping for that shell.
|
|
a shell, it maybe required to do escaping for that shell.
|
|
|
|
|
|
### Isn't the "Expression" in the "ELSE (Expression)" confusing?
|
|
### Isn't the "Expression" in the "else(Expression)" confusing?
|
|
|
|
|
|
Traditional CMakeLists.txt files prior to 2.6.0, require the following
|
|
Traditional CMakeLists.txt files prior to 2.6.0, require the following
|
|
syntax. In the IF syntax, the ELSE section requires the same
|
|
syntax. In the `if` syntax, the `else` section requires the same
|
|
(Expression) as the IF section. This sometimes can make the script kind
|
|
(Expression) as the `if` section. This sometimes can make the script kind
|
|
of hard to follow, take the short example below:
|
|
of hard to follow, take the short example below:
|
|
|
|
|
|
IF(WIN32)
|
|
```cmake
|
|
...do something...
|
|
if(WIN32)
|
|
ELSE(WIN32)
|
|
...do something...
|
|
...do something else...
|
|
else(WIN32)
|
|
ENDIF(WIN32)
|
|
...do something else...
|
|
|
|
endif(WIN32)
|
|
You might think that the ELSE section, here containing "...do something
|
|
```
|
|
|
|
You might think that the `else` section, here containing "...do something
|
|
else...", is for the WIN32 portion of the script. That is not so\! It is
|
|
else...", is for the WIN32 portion of the script. That is not so\! It is
|
|
actually handling the NOT WIN32 section.
|
|
actually handling the NOT WIN32 section.
|
|
|
|
|
|
As of CMake 2.6.0 the ELSE() and ENDIF() constructs can be empty. The
|
|
As of CMake 2.6.0 the `else()` and `endif()` constructs can be empty. The
|
|
same is true for closing constructs on ENDMACRO(), ENDFUNCTION(), and
|
|
same is true for closing constructs on `endmacro()`, `endfunction()`, and
|
|
ENDFOREACH(). If you require 2.4.x compatibility, CMake 2.4.3 or greater
|
|
`endforeach()`. If you require 2.4.x compatibility, CMake 2.4.3 or greater
|
|
recognizes the CMAKE_ALLOW_LOOSE_LOOP_CONSTRUCTS option (which is
|
|
recognizes the `CMAKE_ALLOW_LOOSE_LOOP_CONSTRUCTS` option (which is
|
|
superfluous in 2.6.0)
|
|
superfluous in 2.6.0)
|
|
|
|
|
|
```
|
|
```cmake
|
|
cmake_minimum_required(VERSION 2.4.3)
|
|
cmake_minimum_required(VERSION 2.4.3)
|
|
set(CMAKE_ALLOW_LOOSE_LOOP_CONSTRUCTS true)
|
|
set(CMAKE_ALLOW_LOOSE_LOOP_CONSTRUCTS true)
|
|
|
|
|
|
if(WIN32)
|
|
if(WIN32)
|
|
...do something...
|
|
...do something...
|
|
elseif(APPLE)
|
|
elseif(APPLE)
|
|
...do something else...
|
|
...do something else...
|
|
else()
|
|
else()
|
|
...do something else...
|
|
...do something else...
|
|
endif()
|
|
endif()
|
|
```
|
|
```
|
|
|
|
|
|
### Which regular expressions are supported by CMake?
|
|
### Which regular expressions are supported by CMake?
|
... | @@ -789,78 +808,80 @@ superfluous in 2.6.0) |
... | @@ -789,78 +808,80 @@ superfluous in 2.6.0) |
|
source at
|
|
source at
|
|
[Source/kwsys/RegularExpression.hxx.in](http://www.cmake.org/cgi-bin/viewcvs.cgi/Source/kwsys/RegularExpression.hxx.in?root=CMake&view=markup))
|
|
[Source/kwsys/RegularExpression.hxx.in](http://www.cmake.org/cgi-bin/viewcvs.cgi/Source/kwsys/RegularExpression.hxx.in?root=CMake&view=markup))
|
|
|
|
|
|
When using MATCHES or MATCHALL in an IF command, or using any of the
|
|
When using `MATCHES` or `MATCHALL` in an `if` command, or using any of the
|
|
STRING(REGEX ...) commands, CMake expects regular expressions, not globs
|
|
`string(REGEX ...)` commands, CMake expects regular expressions, not globs
|
|
(wild cards). CMake uses the same regular expression engine above all
|
|
(wild cards). CMake uses the same regular expression engine above all
|
|
platforms. Here are the meanings of the metacharacters:
|
|
platforms. Here are the meanings of the metacharacters:
|
|
|
|
|
|
^ Matches at beginning of a line
|
|
- `^` Matches at beginning of a line
|
|
$ Matches at end of a line
|
|
- `$` Matches at end of a line
|
|
. Matches any single character
|
|
- `.` Matches any single character
|
|
[ ] Matches any character(s) inside the brackets
|
|
- `[`...`]` Matches any character(s) inside the brackets
|
|
[^ ] Matches any character(s) not inside the brackets
|
|
- `[^`...`]` Matches any character(s) not inside the brackets
|
|
- Matches any character in range on either side of a dash
|
|
- `-` Matches any character in range on either side of a dash
|
|
| Matches a pattern on either side of the |
|
|
- `|` Matches a pattern on either side of the `|`
|
|
* Matches preceding pattern zero or more times
|
|
- `*` Matches preceding pattern zero or more times
|
|
+ Matches preceding pattern one or more times
|
|
- `+` Matches preceding pattern one or more times
|
|
? Matches preceding pattern zero or once only
|
|
- `?` Matches preceding pattern zero or once only
|
|
() Saves a matched expression and uses it in a later match
|
|
- `(`...`)` Saves a matched expression and uses it in a later match
|
|
|
|
|
|
Example: "\[-\]\[L\](\[^ ;\])+" matches all strings beginning with -L
|
|
Example: `\[-\]\[L\](\[^ ;\])+` matches all strings beginning with `-L`
|
|
and ending with a space or a semicolon, the usual linkdirs under Linux.
|
|
and ending with a space or a semicolon, the usual linkdirs under Linux.
|
|
|
|
|
|
Here is how to catch a part of a string. The variable test is filled
|
|
Here is how to catch a part of a string. The variable test is filled
|
|
with some content, and then we want to catch the "me":
|
|
with some content, and then we want to catch the "me":
|
|
|
|
```cmake
|
|
SET(test "hello world ! catch: me if you can")
|
|
set(test "hello world ! catch: me if you can")
|
|
STRING(REGEX REPLACE ".*catch: ([^ ]+).*" "\\1" result "${test}" )
|
|
string(REGEX REPLACE ".*catch: ([^ ]+).*" "\\1" result "${test}" )
|
|
MESSAGE(STATUS "result= ${result}")
|
|
message(STATUS "result= ${result}")
|
|
|
|
```
|
|
This is slightly tricky. The part inside the brackets is available in
|
|
This is slightly tricky. The part inside the brackets is available in
|
|
\\\\1 . CMake will copy the variable test to the variable result, but
|
|
`\\1` . CMake will copy the variable test to the variable result, but
|
|
then it will replace everything that the regular expression matches with
|
|
then it will replace everything that the regular expression matches with
|
|
\\\\1. This means the first regular expression has to match the whole
|
|
`\\1`. This means the first regular expression has to match the whole
|
|
string and the part we want to catch has to be put in parens.
|
|
string and the part we want to catch has to be put in parens.
|
|
|
|
|
|
-- result= me
|
|
-- result= me
|
|
|
|
|
|
For those of you who know Perl, the equivalent Perl code could be:
|
|
For those of you who know Perl, the equivalent Perl code could be:
|
|
|
|
```perl
|
|
$test = "hello world ! catch: me if you can";
|
|
$test = "hello world ! catch: me if you can";
|
|
$result = $test;
|
|
$result = $test;
|
|
$result =~ s/.*catch: ([^ ]+).*/$1/;
|
|
$result =~ s/.*catch: ([^ ]+).*/$1/;
|
|
print "-- result= $result\n";
|
|
print "-- result= $result\n";
|
|
|
|
```
|
|
|
|
|
|
There are other ways to do this in Perl, but this is how we do it in
|
|
There are other ways to do this in Perl, but this is how we do it in
|
|
CMake because \\\\1 does not become a variable like $1 does in perl, so
|
|
CMake because `\1` does not become a variable like `$1` does in Perl, so
|
|
there is no SET(result ${\\\\1}) in CMake.
|
|
there is no `set(result ${\1})` in CMake.
|
|
|
|
|
|
Not sure whether CMake regex implementation supports modifiers for case
|
|
Not sure whether CMake regex implementation supports modifiers for case
|
|
insensitive matching, thus if this is needed it's perhaps best to do
|
|
insensitive matching, thus if this is needed it's perhaps best to do
|
|
matches on a result of string(TOLOWER
|
|
matches on a result of `string(TOLOWER ...)`.
|
|
...).
|
|
|
|
|
|
|
|
### How to convert a semicolon separated list to a whitespace separated string?
|
|
### How to convert a semicolon separated list to a whitespace separated string?
|
|
|
|
|
|
set(foo
|
|
```cmake
|
|
abc.c
|
|
set(foo
|
|
abc.b
|
|
abc.c
|
|
abc.a
|
|
abc.b
|
|
)
|
|
abc.a
|
|
|
|
)
|
|
foreach(arg ${foo})
|
|
|
|
set(bar "${bar} ${arg}")
|
|
foreach(arg ${foo})
|
|
endforeach(arg ${foo})
|
|
set(bar "${bar} ${arg}")
|
|
|
|
endforeach(arg ${foo})
|
|
message("foo: ${foo}")
|
|
|
|
message("bar: ${bar}")
|
|
message("foo: ${foo}")
|
|
|
|
message("bar: ${bar}")
|
|
|
|
```
|
|
|
|
|
|
### How can I build multiple modes without switching ?
|
|
### How can I build multiple modes without switching ?
|
|
|
|
|
|
To build multiple modes (e.g. Debug and Release) in one shot without
|
|
To build multiple modes (e.g. Debug and Release) in one shot without
|
|
constantly running cmake -DCMAKE_BUILD_TYPE=Debug and cmake
|
|
constantly running `cmake -DCMAKE_BUILD_TYPE=Debug` and
|
|
-DCMAKE_BUILD_TYPE=Release in source tree create a directory for
|
|
`cmake -DCMAKE_BUILD_TYPE=Release` in source tree create a directory for
|
|
builds eg.:
|
|
builds, e.g.:
|
|
|
|
|
|
Project-directory/
|
|
Project-directory/
|
|
/Build
|
|
/Build
|
... | @@ -875,14 +896,13 @@ modes as you want, e.g.: |
... | @@ -875,14 +896,13 @@ modes as you want, e.g.: |
|
|
|
|
|
In each of these directories issue a command (assuming that you have
|
|
In each of these directories issue a command (assuming that you have
|
|
CMakeLists.txt directly in Project-directory)
|
|
CMakeLists.txt directly in Project-directory)
|
|
|
|
```shell
|
|
cmake -DCMAKE_BUILD_TYPE=type_of_build ../../
|
|
cmake -DCMAKE_BUILD_TYPE=type_of_build ../../
|
|
|
|
```
|
|
to create a cmake cache configured for requested build type.
|
|
to create a cmake cache configured for requested build type.
|
|
|
|
|
|
Now you can make each build just by entering appropriate directory and
|
|
Now you can make each build just by entering appropriate directory and
|
|
executing a make
|
|
executing a make command.
|
|
command.
|
|
|
|
|
|
|
|
### How can I specify my own configurations (for generators that allow it) ?
|
|
### How can I specify my own configurations (for generators that allow it) ?
|
|
|
|
|
... | @@ -890,62 +910,67 @@ For generators that allow it (like Visual Studio), CMake generates four |
... | @@ -890,62 +910,67 @@ For generators that allow it (like Visual Studio), CMake generates four |
|
configurations by default: Debug, Release, MinSizeRel and
|
|
configurations by default: Debug, Release, MinSizeRel and
|
|
RelWithDebInfo. Many people just need Debug and Release, or need other
|
|
RelWithDebInfo. Many people just need Debug and Release, or need other
|
|
configurations. To modify this, you need to change the variable
|
|
configurations. To modify this, you need to change the variable
|
|
CMAKE_CONFIGURATION_TYPES in the cache:
|
|
`CMAKE_CONFIGURATION_TYPES` in the cache:
|
|
|
|
|
|
if(CMAKE_CONFIGURATION_TYPES)
|
|
```cmake
|
|
set(CMAKE_CONFIGURATION_TYPES Debug Release DebugMX31 ReleaseMX31)
|
|
if(CMAKE_CONFIGURATION_TYPES)
|
|
set(CMAKE_CONFIGURATION_TYPES "${CMAKE_CONFIGURATION_TYPES}" CACHE STRING
|
|
set(CMAKE_CONFIGURATION_TYPES Debug Release DebugMX31 ReleaseMX31)
|
|
"Reset the configurations to what we need"
|
|
set(CMAKE_CONFIGURATION_TYPES "${CMAKE_CONFIGURATION_TYPES}" CACHE STRING
|
|
FORCE)
|
|
"Reset the configurations to what we need"
|
|
endif()
|
|
FORCE)
|
|
|
|
endif()
|
|
|
|
```
|
|
|
|
|
|
Note that the first line checks whether the generator supports multiple
|
|
Note that the first line checks whether the generator supports multiple
|
|
configurations.
|
|
configurations.
|
|
|
|
|
|
If you just want to add your own configurations while keeping the
|
|
If you just want to add your own configurations while keeping the
|
|
default ones, you can use list operations:
|
|
default ones, you can use list operations:
|
|
|
|
```cmake
|
|
if(CMAKE_CONFIGURATION_TYPES)
|
|
if(CMAKE_CONFIGURATION_TYPES)
|
|
list(APPEND CMAKE_CONFIGURATION_TYPES SuperDuper)
|
|
list(APPEND CMAKE_CONFIGURATION_TYPES SuperDuper)
|
|
list(REMOVE_DUPLICATES CMAKE_CONFIGURATION_TYPES)
|
|
list(REMOVE_DUPLICATES CMAKE_CONFIGURATION_TYPES)
|
|
set(CMAKE_CONFIGURATION_TYPES "${CMAKE_CONFIGURATION_TYPES}" CACHE STRING
|
|
set(CMAKE_CONFIGURATION_TYPES "${CMAKE_CONFIGURATION_TYPES}" CACHE STRING
|
|
"Add the configurations that we need"
|
|
"Add the configurations that we need"
|
|
FORCE)
|
|
FORCE)
|
|
endif()
|
|
endif()
|
|
|
|
```
|
|
|
|
|
|
### How can I extend the build modes with a custom made one ?
|
|
### How can I extend the build modes with a custom made one ?
|
|
|
|
|
|
The following code snippet (taken from a CMakeLists.txt) adds a
|
|
The following code snippet (taken from a CMakeLists.txt) adds a
|
|
Maintainer mode:
|
|
"Maintainer" mode:
|
|
|
|
|
|
SET( CMAKE_CXX_FLAGS_MAINTAINER "-Wall -Wabi" CACHE STRING
|
|
```cmake
|
|
"Flags used by the C++ compiler during maintainer builds."
|
|
set(CMAKE_CXX_FLAGS_MAINTAINER "-Wall -Wabi" CACHE STRING
|
|
FORCE )
|
|
"Flags used by the C++ compiler during maintainer builds."
|
|
SET( CMAKE_C_FLAGS_MAINTAINER "-Wall -pedantic" CACHE STRING
|
|
FORCE)
|
|
"Flags used by the C compiler during maintainer builds."
|
|
set(CMAKE_C_FLAGS_MAINTAINER "-Wall -pedantic" CACHE STRING
|
|
FORCE )
|
|
"Flags used by the C compiler during maintainer builds."
|
|
SET( CMAKE_EXE_LINKER_FLAGS_MAINTAINER
|
|
FORCE)
|
|
"-Wl,--warn-unresolved-symbols,--warn-once" CACHE STRING
|
|
set(CMAKE_EXE_LINKER_FLAGS_MAINTAINER
|
|
"Flags used for linking binaries during maintainer builds."
|
|
"-Wl,--warn-unresolved-symbols,--warn-once" CACHE STRING
|
|
FORCE )
|
|
"Flags used for linking binaries during maintainer builds."
|
|
SET( CMAKE_SHARED_LINKER_FLAGS_MAINTAINER
|
|
FORCE)
|
|
"-Wl,--warn-unresolved-symbols,--warn-once" CACHE STRING
|
|
set(CMAKE_SHARED_LINKER_FLAGS_MAINTAINER
|
|
"Flags used by the shared libraries linker during maintainer builds."
|
|
"-Wl,--warn-unresolved-symbols,--warn-once" CACHE STRING
|
|
FORCE )
|
|
"Flags used by the shared libraries linker during maintainer builds."
|
|
MARK_AS_ADVANCED(
|
|
FORCE)
|
|
CMAKE_CXX_FLAGS_MAINTAINER
|
|
mark_as_advanced(
|
|
CMAKE_C_FLAGS_MAINTAINER
|
|
CMAKE_CXX_FLAGS_MAINTAINER
|
|
CMAKE_EXE_LINKER_FLAGS_MAINTAINER
|
|
CMAKE_C_FLAGS_MAINTAINER
|
|
CMAKE_SHARED_LINKER_FLAGS_MAINTAINER )
|
|
CMAKE_EXE_LINKER_FLAGS_MAINTAINER
|
|
# Update the documentation string of CMAKE_BUILD_TYPE for GUIs
|
|
CMAKE_SHARED_LINKER_FLAGS_MAINTAINER)
|
|
SET( CMAKE_BUILD_TYPE "${CMAKE_BUILD_TYPE}" CACHE STRING
|
|
# Update the documentation string of CMAKE_BUILD_TYPE for GUIs
|
|
"Choose the type of build, options are: None Debug Release RelWithDebInfo MinSizeRel Maintainer."
|
|
set(CMAKE_BUILD_TYPE "${CMAKE_BUILD_TYPE}" CACHE STRING
|
|
FORCE )
|
|
"Choose the type of build, options are: None Debug Release RelWithDebInfo MinSizeRel Maintainer."
|
|
|
|
FORCE)
|
|
|
|
```
|
|
|
|
|
|
Notes: The flags used in this example are specific to GCC. Change them
|
|
Notes: The flags used in this example are specific to GCC. Change them
|
|
as needed for your project. Additionally the SET(CMAKE_BUILD_TYPE)
|
|
as needed for your project. Additionally the `set(CMAKE_BUILD_TYPE)`
|
|
command will override a CMAKE_BUILD_TYPE previously set in the
|
|
command will override a `CMAKE_BUILD_TYPE` previously set in the
|
|
CMakeLists.txt. A simple "SET(CMAKE_BUILD_TYPE)" does silently
|
|
CMakeLists.txt. A simple `set(CMAKE_BUILD_TYPE)` does silently
|
|
overwrite, the change is only visible in the GUI if "CACHE" is set when
|
|
overwrite, the change is only visible in the GUI if "CACHE" is set when
|
|
overriding.
|
|
overriding.
|
|
|
|
|
... | @@ -953,21 +978,23 @@ overriding. |
... | @@ -953,21 +978,23 @@ overriding. |
|
|
|
|
|
The code in question is of the form
|
|
The code in question is of the form
|
|
|
|
|
|
set(var "a;b;;c;d") # list 'a', 'b', '', 'c', 'd'
|
|
```cmake
|
|
foreach(v ${var})
|
|
set(var "a;b;;c;d") # list 'a', 'b', '', 'c', 'd'
|
|
# v=a, v=b, v=c, v=d, one at a time
|
|
foreach(v ${var})
|
|
endforeach()
|
|
# v=a, v=b, v=c, v=d, one at a time
|
|
|
|
endforeach()
|
|
and the loop variable 'v' never attains the empty-string value ''. This
|
|
```
|
|
|
|
and the loop variable `v` never attains the empty-string value `''`. This
|
|
is because the `${var}` syntax is an unquoted argument so the CMake
|
|
is because the `${var}` syntax is an unquoted argument so the CMake
|
|
language expands the list and removes the empty value. The foreach
|
|
language expands the list and removes the empty value. The foreach
|
|
command does not even see the empty value. One can verify this because
|
|
command does not even see the empty value. One can verify this because
|
|
the code
|
|
the code
|
|
|
|
|
|
foreach(v a b "" c d)
|
|
```cmake
|
|
...
|
|
foreach(v a b "" c d)
|
|
endforeach()
|
|
...
|
|
|
|
endforeach()
|
|
|
|
```
|
|
will see the empty value.
|
|
will see the empty value.
|
|
|
|
|
|
### Does CMake support precompiled headers?
|
|
### Does CMake support precompiled headers?
|
... | @@ -993,12 +1020,13 @@ repository. |
... | @@ -993,12 +1020,13 @@ repository. |
|
### Why does find_library look in system directories before its PATHS option?
|
|
### Why does find_library look in system directories before its PATHS option?
|
|
|
|
|
|
The code in question is often of the form
|
|
The code in question is often of the form
|
|
|
|
```cmake
|
|
|
|
find_library(FOO_LIBRARY NAMES foo PATHS /opt/foo/lib)
|
|
|
|
```
|
|
|
|
|
|
find_library(FOO_LIBRARY NAMES foo PATHS /opt/foo/lib)
|
|
CMake will find `/usr/lib/libfoo.so` instead of
|
|
|
|
`/opt/foo/lib/libfoo.so` if both exist. The reason is that
|
|
CMake will find "`/usr/lib/libfoo.so`" instead of
|
|
`/opt/foo/lib` is a *hard-coded guess* of the location. The
|
|
"`/opt/foo/lib/libfoo.so`" if both exist. The reason is that
|
|
|
|
/opt/foo/lib is a <i>hard-coded guess</i> of the location. The
|
|
|
|
documentation of
|
|
documentation of
|
|
[`find_library`](http://www.cmake.org/cmake/help/cmake2.6docs.html#command:find_library)
|
|
[`find_library`](http://www.cmake.org/cmake/help/cmake2.6docs.html#command:find_library)
|
|
specifies the search order. User, project, and system configuration
|
|
specifies the search order. User, project, and system configuration
|
... | @@ -1006,15 +1034,16 @@ variables are always more local than hard-coded guesses and should |
... | @@ -1006,15 +1034,16 @@ variables are always more local than hard-coded guesses and should |
|
override them, so the PATHS option is used last.
|
|
override them, so the PATHS option is used last.
|
|
|
|
|
|
Some find-modules compute probable locations based on other information
|
|
Some find-modules compute probable locations based on other information
|
|
<i>available from the system</i> such as a project-specific environment
|
|
*available from the system* such as a project-specific environment
|
|
variable. The HINTS option (CMake 2.6 and higher) takes precedence over
|
|
variable. The HINTS option (CMake 2.6 and higher) takes precedence over
|
|
system directories specifically for this case:
|
|
system directories specifically for this case:
|
|
|
|
```cmake
|
|
|
|
file(TO_CMAKE_PATH "$ENV{FOO_LIB_DIR}" FOO_LIB_DIR)
|
|
|
|
find_library(FOO_LIBRARY NAMES foo HINTS ${FOO_LIB_DIR})
|
|
|
|
```
|
|
|
|
|
|
file(TO_CMAKE_PATH "$ENV{FOO_LIB_DIR}" FOO_LIB_DIR)
|
|
CMake will find `$ENV{FOO_LIB_DIR}/libfoo.so` before
|
|
find_library(FOO_LIBRARY NAMES foo HINTS ${FOO_LIB_DIR})
|
|
`/usr/lib/libfoo.so`.
|
|
|
|
|
|
CMake will find "`$ENV{FOO_LIB_DIR}/libfoo.so`" before
|
|
|
|
"`/usr/lib/libfoo.so`".
|
|
|
|
|
|
|
|
## Finding and using external packages
|
|
## Finding and using external packages
|
|
|
|
|
... | @@ -1022,54 +1051,56 @@ CMake will find "`$ENV{FOO_LIB_DIR}/libfoo.so`" before |
... | @@ -1022,54 +1051,56 @@ CMake will find "`$ENV{FOO_LIB_DIR}/libfoo.so`" before |
|
|
|
|
|
CMake version 2 includes a module that supports the generation of SWIG
|
|
CMake version 2 includes a module that supports the generation of SWIG
|
|
wrapper libraries. The SWIG package defines the following macros:
|
|
wrapper libraries. The SWIG package defines the following macros:
|
|
SWIG_ADD_MODULE and SWIG_LINK_LIBRARIES.
|
|
`swig_add_module` and `swig_link_libraries`.
|
|
|
|
|
|
# This example shows how to use python
|
|
```cmake
|
|
# Currently these languages have been tested:
|
|
# This example shows how to use python
|
|
# perl tcl ruby php4 pike
|
|
# Currently these languages have been tested:
|
|
|
|
# perl tcl ruby php4 pike
|
|
|
|
|
|
FIND_PACKAGE(SWIG REQUIRED)
|
|
find_package(SWIG REQUIRED)
|
|
INCLUDE(${SWIG_USE_FILE})
|
|
include(${SWIG_USE_FILE})
|
|
|
|
|
|
FIND_PACKAGE(PythonLibs)
|
|
find_package(PythonLibs)
|
|
INCLUDE_DIRECTORIES(${PYTHON_INCLUDE_PATH})
|
|
include_directories(${PYTHON_INCLUDE_PATH})
|
|
|
|
|
|
INCLUDE_DIRECTORIES(${CMAKE_CURRENT_SOURCE_DIR})
|
|
include_directories(${CMAKE_CURRENT_SOURCE_DIR})
|
|
|
|
|
|
SET(CMAKE_SWIG_FLAGS "")
|
|
set(CMAKE_SWIG_FLAGS "")
|
|
|
|
|
|
SET_SOURCE_FILES_PROPERTIES(example.i PROPERTIES CPLUSPLUS ON)
|
|
set_source_file_properties(example.i PROPERTIES CPLUSPLUS ON)
|
|
SET_SOURCE_FILES_PROPERTIES(example.i PROPERTIES SWIG_FLAGS "-includeall")
|
|
set_source_file_properties(example.i PROPERTIES SWIG_FLAGS "-includeall")
|
|
SWIG_ADD_MODULE(example python
|
|
swig_add_module(example python
|
|
example.i example.cxx)
|
|
example.i example.cxx)
|
|
SWIG_LINK_LIBRARIES(example ${PYTHON_LIBRARIES})
|
|
swig_link_libraries(example ${PYTHON_LIBRARIES})
|
|
|
|
|
|
# This example shows how to use tcl
|
|
# This example shows how to use tcl
|
|
PROJECT(TCL_WRAP)
|
|
project(TCL_WRAP)
|
|
SET ( MODULE_NAME project )
|
|
set(MODULE_NAME project)
|
|
SET ( INTERFACE_FILES project.i)
|
|
set(INTERFACE_FILES project.i)
|
|
SET ( SRC_FILES Vertex.h Vertex.cxx Shapes.h Shapes.cxx )
|
|
set(SRC_FILES Vertex.h Vertex.cxx Shapes.h Shapes.cxx)
|
|
|
|
|
|
FIND_PACKAGE(SWIG REQUIRED)
|
|
find_package(SWIG REQUIRED)
|
|
INCLUDE(${SWIG_USE_FILE})
|
|
include(${SWIG_USE_FILE})
|
|
|
|
|
|
# Look for TCL
|
|
# Look for TCL
|
|
INCLUDE_DIRECTORIES(${TCL_INCLUDE_PATH})
|
|
include_directories(${TCL_INCLUDE_PATH})
|
|
|
|
|
|
FIND_LIBRARY(TCL_LIBRARY NAMES tcl tcl84 tcl83 tcl82 tcl80
|
|
find_library(TCL_LIBRARY NAMES tcl tcl84 tcl83 tcl82 tcl80
|
|
PATHS /usr/lib /usr/local/lib)
|
|
PATHS /usr/lib /usr/local/lib)
|
|
IF (TCL_LIBRARY)
|
|
if(TCL_LIBRARY)
|
|
TARGET_ADD_LIBRARY (${MODULE_NAME} TCL_LIBRARY)
|
|
target_add_library(${MODULE_NAME} TCL_LIBRARY)
|
|
ENDIF (TCL_LIBRARY)
|
|
endif()
|
|
|
|
|
|
INCLUDE_DIRECTORIES(${CMAKE_CURRENT_SOURCE_DIR})
|
|
include_directories(${CMAKE_CURRENT_SOURCE_DIR})
|
|
|
|
|
|
SET(CMAKE_SWIG_FLAGS "-c++")
|
|
set(CMAKE_SWIG_FLAGS "-c++")
|
|
|
|
|
|
SET_SOURCE_FILES_PROPERTIES(${INTERFACE_FILES} PROPERTIES CPLUSPLUS ON)
|
|
set_source_file_properties(${INTERFACE_FILES} PROPERTIES CPLUSPLUS ON)
|
|
SET_SOURCE_FILES_PROPERTIES(${INTERFACE_FILES} PROPERTIES CMAKE_SWIG_FLAGS "-includeall")
|
|
set_source_file_properties(${INTERFACE_FILES} PROPERTIES CMAKE_SWIG_FLAGS "-includeall")
|
|
SWIG_ADD_MODULE(${MODULE_NAME} tcl ${INTERFACE_FILES} ${SRC_FILES})
|
|
swig_add_module(${MODULE_NAME} tcl ${INTERFACE_FILES} ${SRC_FILES})
|
|
SWIG_LINK_LIBRARIES(${MODULE_NAME} ${TCL_LIBRARIES})
|
|
swig_link_libraries(${MODULE_NAME} ${TCL_LIBRARIES})
|
|
|
|
```
|
|
|
|
|
|
If you get errors indicating that C and C++ include files cannot be
|
|
If you get errors indicating that C and C++ include files cannot be
|
|
found, like,
|
|
found, like,
|
... | @@ -1088,92 +1119,93 @@ found, like, |
... | @@ -1088,92 +1119,93 @@ found, like, |
|
|
|
|
|
try setting the `-includeall` property on fewer source files:
|
|
try setting the `-includeall` property on fewer source files:
|
|
|
|
|
|
# Try doing this on fewer files
|
|
```cmake
|
|
SET_SOURCE_FILES_PROPERTIES(example.i PROPERTIES SWIG_FLAGS "-includeall")
|
|
# Try doing this on fewer files
|
|
|
|
set_source_file_properties(example.i PROPERTIES SWIG_FLAGS "-includeall")
|
|
|
|
```
|
|
|
|
|
|
In particular, you may need `-includeall` only on the top-level `.i`
|
|
In particular, you may need `-includeall` only on the top-level `.i`
|
|
files.
|
|
files.
|
|
|
|
|
|
### How do I use CMake to build LaTeX documents?
|
|
### How do I use CMake to build LaTeX documents?
|
|
|
|
|
|
Use the following approach. Note that you have to set LATEX_COMPILE to
|
|
Use the following approach. Note that you have to set `LATEX_COMPILE` to
|
|
LaTeX executable, DVIPDF_COMPILE to dvi to pdf converter. Also, the
|
|
LaTeX executable, `DVIPDF_COMPILE` to dvi to pdf converter. Also, the
|
|
LaTeX source is TDocument.tex and the result is called TDocument.pdf.
|
|
LaTeX source is TDocument.tex and the result is called TDocument.pdf.
|
|
Note that this uses commands in CMake version 1.8 or later.
|
|
Note that this uses commands in CMake version 1.8 or later.
|
|
|
|
|
|
PROJECT(Document)
|
|
```cmake
|
|
IF(LATEX_COMPILE)
|
|
project(Document)
|
|
ADD_CUSTOM_COMMAND(
|
|
if(LATEX_COMPILE)
|
|
OUTPUT ${Document_BINARY_DIR}/TDocument.dvi
|
|
add_custom_command(
|
|
DEPENDS ${Document_BINARY_DIR}/TDocument.tex
|
|
OUTPUT ${Document_BINARY_DIR}/TDocument.dvi
|
|
COMMAND ${LATEX_COMPILE}
|
|
DEPENDS ${Document_BINARY_DIR}/TDocument.tex
|
|
ARGS ${Document_SOURCE_DIR}/TDocument.tex
|
|
COMMAND ${LATEX_COMPILE}
|
|
)
|
|
ARGS ${Document_SOURCE_DIR}/TDocument.tex
|
|
ENDIF(LATEX_COMPILE)
|
|
|
|
|
|
|
|
IF(DVIPDF_COMPILE)
|
|
|
|
ADD_CUSTOM_COMMAND(
|
|
|
|
OUTPUT ${Document_BINARY_DIR}/TDocument.pdf
|
|
|
|
DEPENDS ${Document_BINARY_DIR}/TDocument.dvi
|
|
|
|
COMMAND ${DVIPDF_COMPILE}
|
|
|
|
ARGS ${Document_SOURCE_DIR}/TDocument.dvi
|
|
|
|
)
|
|
|
|
ENDIF(DVIPDF_COMPILE)
|
|
|
|
|
|
|
|
ADD_CUSTOM_TARGET(LaTeXDocument ALL echo
|
|
|
|
DEPENDS ${Document_BINARY_DIR}/TDocument.pdf
|
|
|
|
)
|
|
|
|
|
|
|
|
The following uses commands in CMake version 2.0 and later
|
|
|
|
|
|
|
|
PROJECT(Document)
|
|
|
|
#
|
|
|
|
# Find LaTeX
|
|
|
|
#
|
|
|
|
FIND_PACKAGE(LATEX)
|
|
|
|
|
|
|
|
IF(LATEX_COMPILER)
|
|
|
|
ADD_CUSTOM_COMMAND(
|
|
|
|
OUTPUT ${Document_BINARY_DIR}/TDocument.dvi
|
|
|
|
COMMAND ${LATEX_COMPILER}
|
|
|
|
ARGS ${Document_SOURCE_DIR}/TDocument.tex
|
|
|
|
DEPENDS ${Document_SOURCE_DIR}/TDocument.tex
|
|
|
|
COMMENT "Tex2dvi"
|
|
|
|
)
|
|
|
|
|
|
|
|
```
|
|
|
|
IF(DVIPS_CONVERTER)
|
|
|
|
ADD_CUSTOM_COMMAND(
|
|
|
|
OUTPUT ${Document_BINARY_DIR}/TDocument.ps
|
|
|
|
COMMAND ${DVIPS_CONVERTER}
|
|
|
|
ARGS ${Document_BINARY_DIR}/TDocument.dvi
|
|
|
|
-o ${Document_BINARY_DIR}/TDocument.ps
|
|
|
|
DEPENDS ${Document_BINARY_DIR}/TDocument.dvi
|
|
|
|
COMMENT "dvi2ps"
|
|
|
|
)
|
|
|
|
|
|
|
|
IF(PS2PDF_CONVERTER)
|
|
|
|
ADD_CUSTOM_COMMAND(
|
|
|
|
OUTPUT ${Document_BINARY_DIR}/TDocument.pdf
|
|
|
|
COMMAND ${PS2PDF_CONVERTER}
|
|
|
|
ARGS ${Document_BINARY_DIR}/TDocument.ps
|
|
|
|
DEPENDS ${Document_BINARY_DIR}/TDocument.ps
|
|
|
|
COMMENT "ps2pdf"
|
|
|
|
)
|
|
)
|
|
```
|
|
endif()
|
|
|
|
|
|
|
|
if(DVIPDF_COMPILE)
|
|
|
|
add_custom_command(
|
|
|
|
OUTPUT ${Document_BINARY_DIR}/TDocument.pdf
|
|
|
|
DEPENDS ${Document_BINARY_DIR}/TDocument.dvi
|
|
|
|
COMMAND ${DVIPDF_COMPILE}
|
|
|
|
ARGS ${Document_SOURCE_DIR}/TDocument.dvi
|
|
|
|
)
|
|
|
|
endif()
|
|
|
|
|
|
|
|
add_custom_target(LaTeXDocument ALL echo
|
|
|
|
DEPENDS ${Document_BINARY_DIR}/TDocument.pdf
|
|
|
|
)
|
|
```
|
|
```
|
|
ADD_CUSTOM_TARGET(LaTeXDocument ALL echo
|
|
The following uses commands in CMake version 2.0 and later
|
|
DEPENDS ${Document_BINARY_DIR}/TDocument.pdf
|
|
|
|
)
|
|
```cmake
|
|
ENDIF(PS2PDF_CONVERTER)
|
|
project(Document)
|
|
ENDIF(DVIPS_CONVERTER)
|
|
#
|
|
ENDIF(LATEX_COMPILER)
|
|
# Find LaTeX
|
|
|
|
#
|
|
|
|
find_package(LATEX)
|
|
|
|
|
|
|
|
if(LATEX_COMPILER)
|
|
|
|
add_custom_command(
|
|
|
|
OUTPUT ${Document_BINARY_DIR}/TDocument.dvi
|
|
|
|
COMMAND ${LATEX_COMPILER}
|
|
|
|
ARGS ${Document_SOURCE_DIR}/TDocument.tex
|
|
|
|
DEPENDS ${Document_SOURCE_DIR}/TDocument.tex
|
|
|
|
COMMENT "Tex2dvi"
|
|
|
|
)
|
|
|
|
|
|
|
|
if(DVIPS_CONVERTER)
|
|
|
|
add_custom_command(
|
|
|
|
OUTPUT ${Document_BINARY_DIR}/TDocument.ps
|
|
|
|
COMMAND ${DVIPS_CONVERTER}
|
|
|
|
ARGS ${Document_BINARY_DIR}/TDocument.dvi
|
|
|
|
-o ${Document_BINARY_DIR}/TDocument.ps
|
|
|
|
DEPENDS ${Document_BINARY_DIR}/TDocument.dvi
|
|
|
|
COMMENT "dvi2ps"
|
|
|
|
)
|
|
|
|
|
|
|
|
if(PS2PDF_CONVERTER)
|
|
|
|
add_custom_command(
|
|
|
|
OUTPUT ${Document_BINARY_DIR}/TDocument.pdf
|
|
|
|
COMMAND ${PS2PDF_CONVERTER}
|
|
|
|
ARGS ${Document_BINARY_DIR}/TDocument.ps
|
|
|
|
DEPENDS ${Document_BINARY_DIR}/TDocument.ps
|
|
|
|
COMMENT "ps2pdf"
|
|
|
|
)
|
|
|
|
|
|
|
|
add_custom_target(LaTeXDocument ALL echo
|
|
|
|
DEPENDS ${Document_BINARY_DIR}/TDocument.pdf
|
|
|
|
)
|
|
|
|
endif() # PS2PDF_CONVERTER
|
|
|
|
endif() # DVIPS_CONVERTER
|
|
|
|
endif() # LATEX_COMPILER
|
|
```
|
|
```
|
|
|
|
|
|
### How do I get LaTeX references to be correct?
|
|
### How do I get LaTeX references to be correct?
|
|
|
|
|
|
When your latex document contains references (e.g. \\ref{...} command)
|
|
When your latex document contains references (e.g. `\ref{...}` command)
|
|
you get to run two passes of latex. In the most general case, i.e. when
|
|
you get to run two passes of latex. In the most general case, i.e. when
|
|
additionally your document uses a bibtex bibliography, you shall need
|
|
additionally your document uses a bibtex bibliography, you shall need
|
|
three passes of latex (and one pass of bibtex):
|
|
three passes of latex (and one pass of bibtex):
|
... | @@ -1188,54 +1220,56 @@ and latex generated auxilary files (.aux, .log, .dvi, .bbl...) to create |
... | @@ -1188,54 +1220,56 @@ and latex generated auxilary files (.aux, .log, .dvi, .bbl...) to create |
|
an "artificial" set of CMake dependencies. The side-effect of those
|
|
an "artificial" set of CMake dependencies. The side-effect of those
|
|
dependencies should hopefully be the above described sequence of calls
|
|
dependencies should hopefully be the above described sequence of calls
|
|
to latex and bibtex
|
|
to latex and bibtex
|
|
|
|
```cmake
|
|
ADD_CUSTOM_COMMAND(
|
|
add_custom_command(
|
|
OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/UsersManual.aux
|
|
OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/UsersManual.aux
|
|
DEPENDS ${CMAKE_CURRENT_SOURCE_DIR}/UsersManual.tex
|
|
DEPENDS ${CMAKE_CURRENT_SOURCE_DIR}/UsersManual.tex
|
|
COMMAND ${LATEX_COMPILER}
|
|
COMMAND ${LATEX_COMPILER}
|
|
ARGS -interaction=batchmode ${CMAKE_CURRENT_BINARY_DIR}/UsersManual
|
|
ARGS -interaction=batchmode ${CMAKE_CURRENT_BINARY_DIR}/UsersManual
|
|
COMMENT "Latex (first pass)"
|
|
COMMENT "Latex (first pass)"
|
|
)
|
|
)
|
|
|
|
|
|
ADD_CUSTOM_COMMAND(
|
|
add_custom_command(
|
|
OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/UsersManual.bbl
|
|
OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/UsersManual.bbl
|
|
DEPENDS ${CMAKE_CURRENT_BINARY_DIR}/UsersManual.aux
|
|
DEPENDS ${CMAKE_CURRENT_BINARY_DIR}/UsersManual.aux
|
|
COMMAND ${BIBTEX_COMPILER}
|
|
COMMAND ${BIBTEX_COMPILER}
|
|
ARGS -terse ${CMAKE_CURRENT_BINARY_DIR}/UsersManual
|
|
ARGS -terse ${CMAKE_CURRENT_BINARY_DIR}/UsersManual
|
|
COMMENT "Bibtex"
|
|
COMMENT "Bibtex"
|
|
)
|
|
)
|
|
|
|
|
|
ADD_CUSTOM_COMMAND(
|
|
add_custom_command(
|
|
OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/UsersManual.dvi
|
|
OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/UsersManual.dvi
|
|
DEPENDS ${CMAKE_CURRENT_BINARY_DIR}/UsersManual.bbl
|
|
DEPENDS ${CMAKE_CURRENT_BINARY_DIR}/UsersManual.bbl
|
|
COMMAND ${LATEX_COMPILER}
|
|
COMMAND ${LATEX_COMPILER}
|
|
ARGS -interaction=batchmode ${CMAKE_CURRENT_BINARY_DIR}/UsersManual
|
|
ARGS -interaction=batchmode ${CMAKE_CURRENT_BINARY_DIR}/UsersManual
|
|
COMMENT "Latex (second pass)"
|
|
COMMENT "Latex (second pass)"
|
|
)
|
|
)
|
|
|
|
|
|
ADD_CUSTOM_COMMAND(
|
|
add_custom_command(
|
|
OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/UsersManual.log
|
|
OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/UsersManual.log
|
|
DEPENDS ${CMAKE_CURRENT_BINARY_DIR}/UsersManual.bbl
|
|
DEPENDS ${CMAKE_CURRENT_BINARY_DIR}/UsersManual.bbl
|
|
${CMAKE_CURRENT_BINARY_DIR}/UsersManual.dvi
|
|
${CMAKE_CURRENT_BINARY_DIR}/UsersManual.dvi
|
|
COMMAND ${LATEX_COMPILER}
|
|
COMMAND ${LATEX_COMPILER}
|
|
ARGS -interaction=batchmode ${CMAKE_CURRENT_BINARY_DIR}/UsersManual
|
|
ARGS -interaction=batchmode ${CMAKE_CURRENT_BINARY_DIR}/UsersManual
|
|
COMMENT "Latex (third pass)"
|
|
COMMENT "Latex (third pass)"
|
|
)
|
|
)
|
|
# Eventually trigger the whole process
|
|
|
|
ADD_CUSTOM_TARGET(LaTeXDocument ALL echo
|
|
# Eventually trigger the whole process
|
|
DEPENDS ${CMAKE_CURRENT_BINARY_DIR}/UsersManual.log
|
|
add_custom_target(LaTeXDocument ALL echo
|
|
)
|
|
DEPENDS ${CMAKE_CURRENT_BINARY_DIR}/UsersManual.log
|
|
|
|
)
|
|
|
|
```
|
|
|
|
|
|
### How can I set TEXINPUTS for a LaTeX compilation?
|
|
### How can I set TEXINPUTS for a LaTeX compilation?
|
|
|
|
|
|
First note that most often you can avoid using TEXINPUTS by copying all
|
|
First note that most often you can avoid using TEXINPUTS by copying all
|
|
the necessary files (.tex source file and included graphic files e.g.
|
|
the necessary files (.tex source file and included graphic files e.g.
|
|
.eps files) from your PROJECT_SOURCE_DIR hirarchy to your
|
|
.eps files) from your `PROJECT_SOURCE_DIR` hirarchy to your
|
|
PROJECT_BINARY_DIR subdir \[refer to CONFIGURE_FILE with the COPYONLY
|
|
`PROJECT_BINARY_DIR` subdir \[refer to `configure_file` with the COPYONLY
|
|
flag set for copying files\]. Since by default latex uses the current
|
|
flag set for copying files\]. Since by default latex uses the current
|
|
working directory as value for TEXINPUTS you should be all set. As
|
|
working directory as value for TEXINPUTS you should be all set. As
|
|
expected, this trick is quick AND dirty since your concerned
|
|
expected, this trick is quick AND dirty since your concerned
|
|
PROJECT_BINARY_DIR subdir now contains files that are NOT generated by
|
|
`PROJECT_BINARY_DIR` subdir now contains files that are NOT generated by
|
|
CMake (in the sense that those files are not the result of a system
|
|
CMake (in the sense that those files are not the result of a system
|
|
command but were merely duplicated)...
|
|
command but were merely duplicated)...
|
|
|
|
|
... | @@ -1243,52 +1277,51 @@ If you consider it is cleaner or easier to define a TEXINPUTS |
... | @@ -1243,52 +1277,51 @@ If you consider it is cleaner or easier to define a TEXINPUTS |
|
environment variable \[the latex command probably misses a -I flag\] you
|
|
environment variable \[the latex command probably misses a -I flag\] you
|
|
can find an example in the InsightDocuments cvs archive (refer to the
|
|
can find an example in the InsightDocuments cvs archive (refer to the
|
|
section "cvs access" near the bottom of Kitware's ITK download page) or
|
|
section "cvs access" near the bottom of Kitware's ITK download page) or
|
|
use google with keywords "ITK_TEXINPUTS CONFIGURE_FILE". Look at
|
|
use google with keywords `ITK_TEXINPUTS CONFIGURE_FILE`. Look at
|
|
InsightDocuments/CourseWare/Training/Vis2003/Latex/CMakeLists.txt and
|
|
InsightDocuments/CourseWare/Training/Vis2003/Latex/CMakeLists.txt and
|
|
search for e.g. "LaTeXWrapper.sh.in".
|
|
search for e.g. "LaTeXWrapper.sh.in".
|
|
|
|
|
|
Roughly the mechanism goes:
|
|
Roughly the mechanism goes:
|
|
|
|
|
|
- SET ITK_TEXINPUTS with the desired TEXINPUTS
|
|
- `set(ITK_TEXINPUTS ...)` with the desired TEXINPUTS
|
|
- CONFIGURE_FILE
|
|
- `configure_file`
|
|
"InsightDocuments/CourseWare/Training/Vis2003/LaTeXWrapper.sh.in"
|
|
"InsightDocuments/CourseWare/Training/Vis2003/LaTeXWrapper.sh.in"
|
|
which generates an sh shell script setting the shell variable
|
|
which generates an sh shell script setting the shell variable
|
|
TEXINPUTS prior to running the latex command
|
|
TEXINPUTS prior to running the latex command
|
|
- use ADD_CUSTOM_COMMAND to invoke this shell script
|
|
- use `add_custom_command` to invoke this shell script
|
|
|
|
|
|
This very example is Win32 portable (except that LaTeXWrapper.bat.in
|
|
This very example is Win32 portable (except that LaTeXWrapper.bat.in
|
|
generates a .bat shell
|
|
generates a .bat shell script)
|
|
script)
|
|
|
|
|
|
|
|
## Library questions
|
|
## Library questions
|
|
|
|
|
|
### Can I build both shared and static libraries with one ADD_LIBRARY command?
|
|
### Can I build both shared and static libraries with one ADD_LIBRARY command?
|
|
|
|
|
|
No. Each library you build must have a unique target name, i.e. the
|
|
No. Each library you build must have a unique target name, i.e. the
|
|
"libname" field of the ADD_LIBRARY command. That way, CMake can track
|
|
`libname` field of the `add_library` command. That way, CMake can track
|
|
dependencies separately for each library. Libraries can have the same
|
|
dependencies separately for each library. Libraries can have the same
|
|
OUTPUT_NAME, see the SET_TARGET_PROPERTIES command, but this is not
|
|
`OUTPUT_NAME`, see the `set_target_properties` command, but this is not
|
|
the
|
|
the default.
|
|
default.
|
|
|
|
|
|
|
|
### Does that mean I have to build all my library objects twice, once for shared and once for static?\! I don't like that\!
|
|
### Does that mean I have to build all my library objects twice, once for shared and once for static?\! I don't like that\!
|
|
|
|
|
|
In practice, most libraries have different defines and compiler flags
|
|
In practice, most libraries have different defines and compiler flags
|
|
for the shared vs. static cases. So you would have to build all your
|
|
for the shared vs. static cases. So you would have to build all your
|
|
library objects twice anyways. However, if you happen to have
|
|
library objects twice anyways. However, if you happen to have
|
|
***exactly*** the same defines and compiler flags for the shared vs.
|
|
*exactly* the same defines and compiler flags for the shared vs.
|
|
static cases...
|
|
static cases...
|
|
|
|
|
|
...if you're using Linux and a GCC-style linker, you could do the
|
|
...if you're using Linux and a GCC-style linker, you could do the
|
|
following. Note that for this to work correctly on linux, the zzSTATIC
|
|
following. Note that for this to work correctly on linux, the zzSTATIC
|
|
source files should have been compiled with "-fPIC" to ensure they will
|
|
source files should have been compiled with "-fPIC" to ensure they will
|
|
work in a shared library.
|
|
work in a shared library.
|
|
|
|
```cmake
|
|
IF(CMAKE_SYSTEM_NAME STREQUAL "Linux" AND CMAKE_COMPILER_IS_GNUCC)
|
|
if(CMAKE_SYSTEM_NAME STREQUAL "Linux" AND CMAKE_COMPILER_IS_GNUCC)
|
|
ADD_LIBRARY(zzSTATIC STATIC -fPIC)
|
|
add_library(zzSTATIC STATIC -fPIC)
|
|
ADD_LIBRARY(zzDYNAMIC SHARED)
|
|
add_library(zzDYNAMIC SHARED)
|
|
TARGET_LINK_LIBRARIES(zzDYNAMIC -Wl,-whole-archive zzSTATIC -Wl,-no-whole-archive)
|
|
target_link_libraries(zzDYNAMIC -Wl,-whole-archive zzSTATIC -Wl,-no-whole-archive)
|
|
ENDIF(CMAKE_SYSTEM_NAME STREQUAL "Linux" AND CMAKE_COMPILER_IS_GNUCC)
|
|
endif()
|
|
|
|
```
|
|
|
|
|
|
...if you want a cross-platform approach that works on all compilers,
|
|
...if you want a cross-platform approach that works on all compilers,
|
|
not just GCC or Linux, you could extract the locations of previously
|
|
not just GCC or Linux, you could extract the locations of previously
|
... | @@ -1301,28 +1334,31 @@ code. |
... | @@ -1301,28 +1334,31 @@ code. |
|
|
|
|
|
### How do I make my shared and static libraries have the same root name, but different suffixes?
|
|
### How do I make my shared and static libraries have the same root name, but different suffixes?
|
|
|
|
|
|
Set the OUTPUT_NAME of your shared and static libraries to the same
|
|
Set the `OUTPUT_NAME` of your shared and static libraries to the same
|
|
thing.
|
|
thing.
|
|
|
|
|
|
ADD_LIBRARY(foo SHARED ${foo_sources})
|
|
```cmake
|
|
ADD_LIBRARY(foo-static STATIC ${foo_sources})
|
|
add_library(foo SHARED ${foo_sources})
|
|
# The library target "foo" already has a default OUTPUT_NAME of "foo", so we don't need to change it.
|
|
add_library(foo-static STATIC ${foo_sources})
|
|
# The library target "foo-static" has a default OUTPUT_NAME of "foo-static", so change it.
|
|
# The library target "foo" already has a default OUTPUT_NAME of "foo", so we don't need to change it.
|
|
SET_TARGET_PROPERTIES(foo-static PROPERTIES OUTPUT_NAME "foo")
|
|
# The library target "foo-static" has a default OUTPUT_NAME of "foo-static", so change it.
|
|
# Now the library target "foo-static" will be named "foo.lib" with MS tools.
|
|
set_target_properties(foo-static PROPERTIES OUTPUT_NAME "foo")
|
|
# This conflicts with the "foo.lib" import library corresponding to "foo.dll",
|
|
# Now the library target "foo-static" will be named "foo.lib" with MS tools.
|
|
# so we add a "lib" prefix (which is default on other platforms anyway):
|
|
# This conflicts with the "foo.lib" import library corresponding to "foo.dll",
|
|
SET_TARGET_PROPERTIES(foo-static PROPERTIES PREFIX "lib")
|
|
# so we add a "lib" prefix (which is default on other platforms anyway):
|
|
|
|
set_target_properties(foo-static PROPERTIES PREFIX "lib")
|
|
|
|
```
|
|
|
|
|
|
One more detail is needed with CMake 2.6.x and lower (but not CMake 2.8
|
|
One more detail is needed with CMake 2.6.x and lower (but not CMake 2.8
|
|
or higher). If you are building your shared and static libraries in the
|
|
or higher). If you are building your shared and static libraries in the
|
|
same directory, you will also need the following to keep your shared and
|
|
same directory, you will also need the following to keep your shared and
|
|
static libraries from clobbering each other during the
|
|
static libraries from clobbering each other during the build.
|
|
build.
|
|
|
|
|
|
|
|
# Help CMake 2.6.x and lower (not necessary for 2.8 and above, but doesn't hurt):
|
|
```cmake
|
|
SET_TARGET_PROPERTIES(foo PROPERTIES CLEAN_DIRECT_OUTPUT 1)
|
|
# Help CMake 2.6.x and lower (not necessary for 2.8 and above, but doesn't hurt):
|
|
SET_TARGET_PROPERTIES(foo-static PROPERTIES CLEAN_DIRECT_OUTPUT 1)
|
|
set_target_properties(foo PROPERTIES CLEAN_DIRECT_OUTPUT 1)
|
|
|
|
set_target_properties(foo-static PROPERTIES CLEAN_DIRECT_OUTPUT 1)
|
|
|
|
```
|
|
|
|
|
|
### How do I rename a library after it has already been built?
|
|
### How do I rename a library after it has already been built?
|
|
|
|
|
... | @@ -1331,24 +1367,25 @@ CMakeLists.txt says it's supposed to be. |
... | @@ -1331,24 +1367,25 @@ CMakeLists.txt says it's supposed to be. |
|
|
|
|
|
Perhaps you want to copy the library to a different name. But, are you
|
|
Perhaps you want to copy the library to a different name. But, are you
|
|
sure that's what you want to do? You could just change the name in your
|
|
sure that's what you want to do? You could just change the name in your
|
|
ADD_LIBRARY command or change its OUTPUT_NAME property using
|
|
`add_library` command or change its OUTPUT_NAME property using
|
|
SET_TARGET_PROPERTY(). If you really really want to copy the library
|
|
`set_target_property()`. If you really really want to copy the library
|
|
to a different name, try:
|
|
to a different name, try:
|
|
|
|
|
|
GET_TARGET_PROPERTY(LIB_NAME Foo LOCATION)
|
|
```cmake
|
|
GET_TARGET_PROPERTY(Bar_prefix Foo PREFIX)
|
|
get_target_property(LIB_NAME Foo LOCATION)
|
|
GET_TARGET_PROPERTY(Bar_suffix Foo SUFFIX)
|
|
get_target_property(Bar_prefix Foo PREFIX)
|
|
SET(NEW_LIB_NAME ${Bar_prefix}Bar${Bar_suffix})
|
|
get_target_property(Bar_suffix Foo SUFFIX)
|
|
|
|
set(NEW_LIB_NAME ${Bar_prefix}Bar${Bar_suffix})
|
|
ADD_CUSTOM_COMMAND(
|
|
|
|
TARGET Foo
|
|
add_custom_command(
|
|
POST_BUILD
|
|
TARGET Foo
|
|
COMMAND ${CMAKE_COMMAND} -E copy ${LIB_NAME} ${NEW_LIB_NAME}
|
|
POST_BUILD
|
|
)
|
|
COMMAND ${CMAKE_COMMAND} -E copy ${LIB_NAME} ${NEW_LIB_NAME}
|
|
|
|
)
|
|
|
|
```
|
|
On Windows you may also want to copy the .dll import lib, using the same
|
|
On Windows you may also want to copy the .dll import lib, using the same
|
|
approach as above, but with IMPORT_PREFIX and IMPORT_SUFFIX. *Problem:
|
|
approach as above, but with `IMPORT_PREFIX` and `IMPORT_SUFFIX`. *Problem:
|
|
LOCATION only refers to 1 file, the .dll. What is a simple way to get
|
|
`LOCATION` only refers to 1 file, the .dll. What is a simple way to get
|
|
the location of the import lib? Could provide a complicated way, but
|
|
the location of the import lib? Could provide a complicated way, but
|
|
that's annoying.*
|
|
that's annoying.*
|
|
|
|
|
... | @@ -1378,8 +1415,9 @@ default behavior provided by CMake with the simple |
... | @@ -1378,8 +1415,9 @@ default behavior provided by CMake with the simple |
|
`PRIVATE`, and `INTERFACE` options to target_link_libraries to specify
|
|
`PRIVATE`, and `INTERFACE` options to target_link_libraries to specify
|
|
whether linking should be used for just the implementation and/or made
|
|
whether linking should be used for just the implementation and/or made
|
|
part of the interface (transitive dependencies):
|
|
part of the interface (transitive dependencies):
|
|
|
|
```cmake
|
|
target_link_libraries(myLibrary PRIVATE myImplDependency)
|
|
target_link_libraries(myLibrary PRIVATE myImplDependency)
|
|
|
|
```
|
|
|
|
|
|
CMake 2.8.7 and above provide `LINK_PUBLIC` and `LINK_PRIVATE` options
|
|
CMake 2.8.7 and above provide `LINK_PUBLIC` and `LINK_PRIVATE` options
|
|
for the same purpose (these were superseded by PUBLIC/PRIVATE/INTERFACE
|
|
for the same purpose (these were superseded by PUBLIC/PRIVATE/INTERFACE
|
... | @@ -1390,11 +1428,11 @@ in 3.0 for consistency with options other commands like |
... | @@ -1390,11 +1428,11 @@ in 3.0 for consistency with options other commands like |
|
|
|
|
|
CMake does not preprocess source files while scanning dependencies. Code
|
|
CMake does not preprocess source files while scanning dependencies. Code
|
|
like
|
|
like
|
|
|
|
```
|
|
#if 0
|
|
#if 0
|
|
# include "bla.h"
|
|
# include "bla.h"
|
|
#endif
|
|
#endif
|
|
|
|
```
|
|
will result in a dependency on "bla.h". This sometimes leads to source
|
|
will result in a dependency on "bla.h". This sometimes leads to source
|
|
files recompiling unnecessarily but will not break the build.
|
|
files recompiling unnecessarily but will not break the build.
|
|
|
|
|
... | @@ -1412,11 +1450,11 @@ For example, if the Makefile generator is used, then all of the |
... | @@ -1412,11 +1450,11 @@ For example, if the Makefile generator is used, then all of the |
|
following are example usages of DESTDIR (perhaps assuming the bash shell
|
|
following are example usages of DESTDIR (perhaps assuming the bash shell
|
|
for the last 2):
|
|
for the last 2):
|
|
|
|
|
|
(1) make install DESTDIR="/some/absolute/path"
|
|
1. `make install DESTDIR="/some/absolute/path"`
|
|
(2) make DESTDIR="/some/absolute/path" install
|
|
2. `make DESTDIR="/some/absolute/path" install`
|
|
(3) DESTDIR="/some/absolute/path" make install
|
|
3. `DESTDIR="/some/absolute/path" make install`
|
|
(4) export DESTDIR="/some/absolute/path
|
|
4. `export DESTDIR="/some/absolute/path`<br/>
|
|
make install
|
|
`make install`
|
|
|
|
|
|
### Can I do "make uninstall" with CMake?
|
|
### Can I do "make uninstall" with CMake?
|
|
|
|
|
... | @@ -1429,55 +1467,57 @@ you from providing one. You need to delete the files listed in |
... | @@ -1429,55 +1467,57 @@ you from providing one. You need to delete the files listed in |
|
install_manifest.txt file. Here is how to do it. First create file
|
|
install_manifest.txt file. Here is how to do it. First create file
|
|
cmake_uninstall.cmake.in in the top-level directory of the project:
|
|
cmake_uninstall.cmake.in in the top-level directory of the project:
|
|
|
|
|
|
if(NOT EXISTS "@CMAKE_BINARY_DIR@/install_manifest.txt")
|
|
```cmake
|
|
message(FATAL_ERROR "Cannot find install manifest: @CMAKE_BINARY_DIR@/install_manifest.txt")
|
|
if(NOT EXISTS "@CMAKE_BINARY_DIR@/install_manifest.txt")
|
|
endif(NOT EXISTS "@CMAKE_BINARY_DIR@/install_manifest.txt")
|
|
message(FATAL_ERROR "Cannot find install manifest: @CMAKE_BINARY_DIR@/install_manifest.txt")
|
|
|
|
endif()
|
|
file(READ "@CMAKE_BINARY_DIR@/install_manifest.txt" files)
|
|
|
|
string(REGEX REPLACE "\n" ";" files "${files}")
|
|
file(READ "@CMAKE_BINARY_DIR@/install_manifest.txt" files)
|
|
foreach(file ${files})
|
|
string(REGEX REPLACE "\n" ";" files "${files}")
|
|
message(STATUS "Uninstalling $ENV{DESTDIR}${file}")
|
|
foreach(file ${files})
|
|
if(IS_SYMLINK "$ENV{DESTDIR}${file}" OR EXISTS "$ENV{DESTDIR}${file}")
|
|
message(STATUS "Uninstalling $ENV{DESTDIR}${file}")
|
|
exec_program(
|
|
if(IS_SYMLINK "$ENV{DESTDIR}${file}" OR EXISTS "$ENV{DESTDIR}${file}")
|
|
"@CMAKE_COMMAND@" ARGS "-E remove \"$ENV{DESTDIR}${file}\""
|
|
exec_program(
|
|
OUTPUT_VARIABLE rm_out
|
|
"@CMAKE_COMMAND@" ARGS "-E remove \"$ENV{DESTDIR}${file}\""
|
|
RETURN_VALUE rm_retval
|
|
OUTPUT_VARIABLE rm_out
|
|
)
|
|
RETURN_VALUE rm_retval
|
|
if(NOT "${rm_retval}" STREQUAL 0)
|
|
)
|
|
message(FATAL_ERROR "Problem when removing $ENV{DESTDIR}${file}")
|
|
if(NOT "${rm_retval}" STREQUAL 0)
|
|
endif(NOT "${rm_retval}" STREQUAL 0)
|
|
message(FATAL_ERROR "Problem when removing $ENV{DESTDIR}${file}")
|
|
else(IS_SYMLINK "$ENV{DESTDIR}${file}" OR EXISTS "$ENV{DESTDIR}${file}")
|
|
|
|
message(STATUS "File $ENV{DESTDIR}${file} does not exist.")
|
|
|
|
endif(IS_SYMLINK "$ENV{DESTDIR}${file}" OR EXISTS "$ENV{DESTDIR}${file}")
|
|
|
|
endforeach(file)
|
|
|
|
|
|
|
|
Then in the top-level CMakeLists.txt add the following logic:
|
|
|
|
|
|
|
|
# uninstall target
|
|
|
|
if(NOT TARGET uninstall)
|
|
|
|
configure_file(
|
|
|
|
"${CMAKE_CURRENT_SOURCE_DIR}/cmake_uninstall.cmake.in"
|
|
|
|
"${CMAKE_CURRENT_BINARY_DIR}/cmake_uninstall.cmake"
|
|
|
|
IMMEDIATE @ONLY)
|
|
|
|
|
|
|
|
add_custom_target(uninstall
|
|
|
|
COMMAND ${CMAKE_COMMAND} -P ${CMAKE_CURRENT_BINARY_DIR}/cmake_uninstall.cmake)
|
|
|
|
endif()
|
|
endif()
|
|
|
|
else(IS_SYMLINK "$ENV{DESTDIR}${file}" OR EXISTS "$ENV{DESTDIR}${file}")
|
|
|
|
message(STATUS "File $ENV{DESTDIR}${file} does not exist.")
|
|
|
|
endif()
|
|
|
|
endforeach()
|
|
|
|
```
|
|
|
|
|
|
|
|
Then in the top-level CMakeLists.txt add the following logic:
|
|
|
|
```cmake
|
|
|
|
# uninstall target
|
|
|
|
if(NOT TARGET uninstall)
|
|
|
|
configure_file(
|
|
|
|
"${CMAKE_CURRENT_SOURCE_DIR}/cmake_uninstall.cmake.in"
|
|
|
|
"${CMAKE_CURRENT_BINARY_DIR}/cmake_uninstall.cmake"
|
|
|
|
IMMEDIATE @ONLY)
|
|
|
|
|
|
|
|
add_custom_target(uninstall
|
|
|
|
COMMAND ${CMAKE_COMMAND} -P ${CMAKE_CURRENT_BINARY_DIR}/cmake_uninstall.cmake)
|
|
|
|
endif()
|
|
|
|
```
|
|
Now you will have an "uninstall" target at the top-level directory of
|
|
Now you will have an "uninstall" target at the top-level directory of
|
|
your build tree.
|
|
your build tree.
|
|
|
|
|
|
Instead of creating an "uninstall" target, Unix users could enter this
|
|
Instead of creating an "uninstall" target, Unix users could enter this
|
|
command in the shell:
|
|
command in the shell:
|
|
|
|
```shell
|
|
xargs rm < install_manifest.txt
|
|
xargs rm < install_manifest.txt
|
|
|
|
```
|
|
|
|
|
|
## Distribution questions
|
|
## Distribution questions
|
|
|
|
|
|
### Where is "make dist"?
|
|
### Where is "make dist"?
|
|
|
|
|
|
CMake doesn't create a "make dist"
|
|
CMake doesn't create a `make dist` target.
|
|
target.
|
|
|
|
|
|
|
|
### What is the best way to distribute source code or binaries for a cmake-based project?
|
|
### What is the best way to distribute source code or binaries for a cmake-based project?
|
|
|
|
|
... | @@ -1492,27 +1532,27 @@ Of course you can also use any other ways to create packages. |
... | @@ -1492,27 +1532,27 @@ Of course you can also use any other ways to create packages. |
|
### How do I build universal binaries on Mac OS X?
|
|
### How do I build universal binaries on Mac OS X?
|
|
|
|
|
|
Before running CMake with an empty build tree, set the
|
|
Before running CMake with an empty build tree, set the
|
|
CMAKE_OSX_ARCHITECTURES environment variable. It should be set to
|
|
`CMAKE_OSX_ARCHITECTURES` environment variable. It should be set to
|
|
contain a ; separated list of architectures that you want in the binary.
|
|
contain a `;` separated list of architectures that you want in the binary.
|
|
For example, for 32-bit PowerPC and Intel you would do this:
|
|
For example, for 32-bit PowerPC and Intel you would do this:
|
|
|
|
|
|
CMAKE_OSX_ARCHITECTURES=ppc;i386
|
|
CMAKE_OSX_ARCHITECTURES=ppc;i386
|
|
|
|
|
|
If you wish to build both as 32 and 64 bit, do this:
|
|
If you wish to build both as 32 and 64 bit, do this:
|
|
|
|
|
|
CMAKE_OSX_ARCHITECTURES=ppc;i386;ppc64;x86_64
|
|
CMAKE_OSX_ARCHITECTURES=ppc;i386;ppc64;x86_64
|
|
|
|
|
|
You can also set the same named CMake cache variable on an existing
|
|
You can also set the same named CMake cache variable on an existing
|
|
binary tree. This works with both makefiles and the Xcode generator.
|
|
binary tree. This works with both makefiles and the Xcode generator.
|
|
|
|
|
|
In addition, you can also set the CMAKE_OSX_SYSROOT variable to point
|
|
In addition, you can also set the `CMAKE_OSX_SYSROOT` variable to point
|
|
to the sysroot (aka Mac OS SDK) to be used. CMake will attempt to pick
|
|
to the sysroot (aka Mac OS SDK) to be used. CMake will attempt to pick
|
|
one on your system, but it can be changed in the cache or via an
|
|
one on your system, but it can be changed in the cache or via an
|
|
environment variable before running CMake. The 10.4u SDK or later must
|
|
environment variable before running CMake. The 10.4u SDK or later must
|
|
be used to create a Universal Binary.
|
|
be used to create a Universal Binary.
|
|
|
|
|
|
Universal Binaries are essentially cross compilation and so you should
|
|
Universal Binaries are essentially cross compilation and so you should
|
|
avoid using TRY_RUN, especially for things like testing endianess or
|
|
avoid using `try_run`, especially for things like testing endianess or
|
|
variable size because the result will only be correct for one
|
|
variable size because the result will only be correct for one
|
|
architecture.
|
|
architecture.
|
|
|
|
|
... | @@ -1521,22 +1561,21 @@ Lastly, note that CTest is only able to test one architecture. See bug |
... | @@ -1521,22 +1561,21 @@ Lastly, note that CTest is only able to test one architecture. See bug |
|
|
|
|
|
### How can I apply resources on Mac OS X automatically?
|
|
### How can I apply resources on Mac OS X automatically?
|
|
|
|
|
|
Using ADD_CUSTOM_COMMAND. For example, let's say you are creating
|
|
Using `add_custom_command`. For example, let's say you are creating
|
|
executable MyExecutable, which needs the resources file Carbon.r. All
|
|
executable MyExecutable, which needs the resources file Carbon.r. All
|
|
you do is add a custom rule which is executed after the executable is
|
|
you do is add a custom rule which is executed after the executable is
|
|
linked:
|
|
linked:
|
|
|
|
```cmake
|
|
```
|
|
add_executable(MyExecutable ${MyExecutable_SRCS})
|
|
ADD_EXECUTABLE(MyExecutable ${MyExecutable_SRCS})
|
|
get_target_property(MyExecutable_PATH MyExecutable LOCATION)
|
|
GET_TARGET_PROPERTY(MyExecutable_PATH MyExecutable LOCATION)
|
|
|
|
|
|
if(APPLE)
|
|
IF(APPLE)
|
|
find_program(APPLE_RESOURCE Rez /Developer/Tools)
|
|
FIND_PROGRAM(APPLE_RESOURCE Rez /Developer/Tools)
|
|
if(APPLE_RESOURCE)
|
|
IF(APPLE_RESOURCE)
|
|
add_custom_command(TARGET MyExecutable POST_BUILD
|
|
ADD_CUSTOM_COMMAND(TARGET MyExecutable POST_BUILD
|
|
COMMAND ${APPLE_RESOURCE} Carbon.r -o ${MyExecutable_PATH})
|
|
COMMAND ${APPLE_RESOURCE} Carbon.r -o ${MyExecutable_PATH})
|
|
endif()
|
|
ENDIF(APPLE_RESOURCE)
|
|
endif()
|
|
ENDIF(APPLE)
|
|
|
|
```
|
|
```
|
|
|
|
|
|
This will execute:
|
|
This will execute:
|
... | @@ -1549,7 +1588,7 @@ after MyExecutable is linked. |
... | @@ -1549,7 +1588,7 @@ after MyExecutable is linked. |
|
OS X and Xcode. You can use 'which Rez' in Terminal to find it's full
|
|
OS X and Xcode. You can use 'which Rez' in Terminal to find it's full
|
|
path.
|
|
path.
|
|
|
|
|
|
### Why does FIND_LIBRARY not find .DLL libraries under WIN32?
|
|
### Why does find_library not find .DLL libraries under WIN32?
|
|
|
|
|
|
For those who come from a Unix background to MS Windows:
|
|
For those who come from a Unix background to MS Windows:
|
|
|
|
|
... | @@ -1574,16 +1613,16 @@ Some more details can be found here: |
... | @@ -1574,16 +1613,16 @@ Some more details can be found here: |
|
|
|
|
|
Your program is a GUI application using WinMain (/subsystem:windows) and
|
|
Your program is a GUI application using WinMain (/subsystem:windows) and
|
|
not a console application using main. You have to use the WIN32 option
|
|
not a console application using main. You have to use the WIN32 option
|
|
with the ADD_EXECUTABLE command.
|
|
with the `add_executable` command.
|
|
|
|
```cmake
|
|
ADD_EXECUTABLE(exename WIN32 source1 source2 ... sourceN)
|
|
add_executable(exename WIN32 source1 source2 ... sourceN)
|
|
|
|
```
|
|
|
|
|
|
The second argument to ADD_EXECUTABLE can be WIN32. This indicates that
|
|
The second argument to `add_executable` can be `WIN32`. This indicates that
|
|
the executable, when compiled on Windows, is a Windows app (using
|
|
the executable, when compiled on Windows, is a Windows app (using
|
|
WinMain) and not a console app (using main). Please note that on Unix
|
|
WinMain) and not a console app (using main). Please note that on Unix
|
|
platforms, CMake ignores the WIN32 and the compiler will use "main" in
|
|
platforms, CMake ignores the WIN32 and the compiler will use "main" in
|
|
any
|
|
any case.
|
|
case.
|
|
|
|
|
|
|
|
### Why do I get this error: nafxcwd.lib(appcore.obj) : error LNK2001: unresolved external symbol ___argv
|
|
### Why do I get this error: nafxcwd.lib(appcore.obj) : error LNK2001: unresolved external symbol ___argv
|
|
|
|
|
... | @@ -1591,25 +1630,28 @@ This is because the application is using both the static and dll |
... | @@ -1591,25 +1630,28 @@ This is because the application is using both the static and dll |
|
versions of the MFC library. To fix the problem, you can do the
|
|
versions of the MFC library. To fix the problem, you can do the
|
|
following:
|
|
following:
|
|
|
|
|
|
SET(CMAKE_MFC_FLAG 2) # force the IDE to use static MFC
|
|
```cmake
|
|
ADD_DEFINITIONS(-D_AFXDLL) # make sure if afx.h is included the dll MFC is used
|
|
set(CMAKE_MFC_FLAG 2) # force the IDE to use static MFC
|
|
|
|
add_definitions(-D_AFXDLL) # make sure if afx.h is included the dll MFC is used
|
|
|
|
```
|
|
|
|
|
|
### How to use MFC with CMake
|
|
### How to use MFC with CMake
|
|
|
|
|
|
To use MFC, the CMAKE_MFC_FLAG variable must be set as follows:
|
|
To use MFC, the `CMAKE_MFC_FLAG` variable must be set as follows:
|
|
|
|
|
|
0: Use Standard Windows Libraries
|
|
0. Use Standard Windows Libraries
|
|
1: Use MFC in a Static Library
|
|
1. Use MFC in a Static Library
|
|
2: Use MFC in a Shared DLL
|
|
2. Use MFC in a Shared DLL
|
|
|
|
|
|
This can be set in a CMakeLists.txt file and will enable MFC in the
|
|
This can be set in a CMakeLists.txt file and will enable MFC in the
|
|
application. It should be set to 1 or 2. This is used in visual studio 6
|
|
application. It should be set to 1 or 2. This is used in visual studio 6
|
|
and 7 project files. The CMakeSetup dialog uses MFC and the
|
|
and 7 project files. The CMakeSetup dialog uses MFC and the
|
|
CMakeLists.txt looks like this:
|
|
CMakeLists.txt looks like this:
|
|
|
|
```cmake
|
|
ADD_DEFINITIONS(-D_AFXDLL)
|
|
add_definitions(-D_AFXDLL)
|
|
SET(CMAKE_MFC_FLAG 2)
|
|
set(CMAKE_MFC_FLAG 2)
|
|
ADD_EXECUTABLE(CMakeSetup WIN32 ${SRCS})
|
|
add_executable(CMakeSetup WIN32 ${SRCS})
|
|
|
|
```
|
|
|
|
|
|
Note that visual studio 9 project files do not appear to work with
|
|
Note that visual studio 9 project files do not appear to work with
|
|
CMAKE_MFC_FLAG 1; this may be related to
|
|
CMAKE_MFC_FLAG 1; this may be related to
|
... | @@ -1618,52 +1660,52 @@ CMAKE_MFC_FLAG 1; this may be related to |
... | @@ -1618,52 +1660,52 @@ CMAKE_MFC_FLAG 1; this may be related to |
|
In order to use MFC with UNICODE, you must also [specify the entry point
|
|
In order to use MFC with UNICODE, you must also [specify the entry point
|
|
wWinMainCRTStartup](http://msdn.microsoft.com/en-us/library/dybsewaf.aspx).
|
|
wWinMainCRTStartup](http://msdn.microsoft.com/en-us/library/dybsewaf.aspx).
|
|
For example:
|
|
For example:
|
|
|
|
```cmake
|
|
set(CMAKE_MFC_FLAG 2)
|
|
set(CMAKE_MFC_FLAG 2)
|
|
set_target_properties(MyApp PROPERTIES
|
|
set_target_properties(MyApp PROPERTIES
|
|
COMPILE_DEFINITIONS _AFXDLL,_UNICODE,UNICODE,_BIND_TO_CURRENT_CRT_VERSION,_BIND_TO_CURRENT_MFC_VERSION
|
|
COMPILE_DEFINITIONS _AFXDLL,_UNICODE,UNICODE,_BIND_TO_CURRENT_CRT_VERSION,_BIND_TO_CURRENT_MFC_VERSION
|
|
LINK_FLAGS "/ENTRY:\"wWinMainCRTStartup\"")
|
|
LINK_FLAGS "/ENTRY:\"wWinMainCRTStartup\"")
|
|
|
|
```
|
|
|
|
|
|
See [this
|
|
See [this
|
|
article](http://stackoverflow.com/questions/59635/app-does-not-run-with-vs-2008-sp1-dlls-previous-version-works-with-rtm-versions)
|
|
article](http://stackoverflow.com/questions/59635/app-does-not-run-with-vs-2008-sp1-dlls-previous-version-works-with-rtm-versions)
|
|
as to why _BIND_TO_CURRENT_CRT_VERSION and
|
|
as to why `_BIND_TO_CURRENT_CRT_VERSION` and `_BIND_TO_CURRENT_MFC_VERSION`
|
|
_BIND_TO_CURRENT_MFC_VERSION are necessary for Visual Studio 2008
|
|
are necessary for Visual Studio 2008 SP1.
|
|
SP1.
|
|
|
|
|
|
|
|
### How To Put Files in Folders in Visual Studio Projects
|
|
### How To Put Files in Folders in Visual Studio Projects
|
|
|
|
|
|
The Visual Studio IDE supports putting files into folders. CMake can be
|
|
The Visual Studio IDE supports putting files into folders. CMake can be
|
|
used to put files in folders with the SOURCE_GROUP command.
|
|
used to put files in folders with the `source_group` command.
|
|
|
|
|
|
SOURCE_GROUP(name [REGULAR_EXPRESSION regex] [FILES src1 src2 ...])
|
|
|
|
|
|
|
|
|
|
```cmake
|
|
|
|
source_group(name [REGULAR_EXPRESSION regex] [FILES src1 src2 ...])
|
|
|
|
```
|
|
Defines a group into which sources will be placed in project files. This
|
|
Defines a group into which sources will be placed in project files. This
|
|
is mainly used to setup file tabs in Visual Studio. Any file whose name
|
|
is mainly used to setup file tabs in Visual Studio. Any file whose name
|
|
is listed or matches the regular expression will be placed in this group
|
|
is listed or matches the regular expression will be placed in this group
|
|
provided the source file is being passed to ADD_EXECUTABLE or
|
|
provided the source file is being passed to `add_executable` or
|
|
ADD_LIBRARY.
|
|
`add_library`. For example:
|
|
|
|
```cmake
|
|
For example:
|
|
source_group(FooFiles FILES foo.cxx)
|
|
SOURCE_GROUP(FooFiles FILES foo.cxx)
|
|
source_group(BarFiles FILES bar.cxx)
|
|
SOURCE_GROUP(BarFiles FILES bar.cxx)
|
|
add_library(foo foo.cxx bar.cxx)
|
|
ADD_LIBRARY(foo foo.cxx bar.cxx)
|
|
```
|
|
|
|
|
|
In the event a file matches multiple groups, the LAST group that
|
|
In the event a file matches multiple groups, the LAST group that
|
|
explicitly lists the file will be favored, if any. If no group
|
|
explicitly lists the file will be favored, if any. If no group
|
|
explicitly lists the file, the LAST group whose regular expression
|
|
explicitly lists the file, the LAST group whose regular expression
|
|
matches the file will be favored. For backwards compatibility this
|
|
matches the file will be favored. For backwards compatibility this
|
|
command is also supports the format SOURCE_GROUP(name regex).
|
|
command is also supports the format `source_group(name regex)`.
|
|
|
|
|
|
As a convenience to developers CMake automatically adds standard header
|
|
As a convenience to developers CMake automatically adds standard header
|
|
files to a "Header Files" folder and standard source files to a "Source
|
|
files to a "Header Files" folder and standard source files to a "Source
|
|
Files" folder for Visual Studio Projects. This can be overridden via the
|
|
Files" folder for Visual Studio Projects. This can be overridden via the
|
|
SOURCE_GROUP method documented
|
|
`source_group` method documented above.
|
|
above.
|
|
|
|
|
|
|
|
### How to create Visual Studio 6 Projects that contain only a single build type
|
|
### How to create Visual Studio 6 Projects that contain only a single build type
|
|
|
|
|
|
For Visual Studio.NET (version 7.0 and above) it is possible to set the
|
|
For Visual Studio.NET (version 7.0 and above) it is possible to set the
|
|
CMAKE_CONFIGURATION_TYPES variable to the build type(s)
|
|
`CMAKE_CONFIGURATION_TYPES` variable to the build type(s)
|
|
(Debug/Release/...) that you want. This does not work for Visual Studio
|
|
(Debug/Release/...) that you want. This does not work for Visual Studio
|
|
6. There is however a way to achieve this. To create your own set of
|
|
6. There is however a way to achieve this. To create your own set of
|
|
configurations:
|
|
configurations:
|
... | @@ -1671,11 +1713,11 @@ configurations: |
... | @@ -1671,11 +1713,11 @@ configurations: |
|
1. Create a directory in which you copy the files \*.dsptemplate and
|
|
1. Create a directory in which you copy the files \*.dsptemplate and
|
|
CMakeVisualStudio6Configurations.cmake from CMake's Templates
|
|
CMakeVisualStudio6Configurations.cmake from CMake's Templates
|
|
directory.
|
|
directory.
|
|
2. Edit the .cmake file and change the SET(CMAKE_CONFIGURATION_TYPES
|
|
2. Edit the .cmake file and change the `set(CMAKE_CONFIGURATION_TYPES ...)`
|
|
...) line to set the build types that you want in your set.
|
|
line to set the build types that you want in your set.
|
|
3. Edit the \*Header.dsptemplate files to contain only the
|
|
3. Edit the \*Header.dsptemplate files to contain only the
|
|
configuration types you want in your set.
|
|
configuration types you want in your set.
|
|
4. In your CMakeLists.txt file, set the MSPROJECT_TEMPLATE_DIRECTORY
|
|
4. In your CMakeLists.txt file, set the `MSPROJECT_TEMPLATE_DIRECTORY`
|
|
to the directory that you created.
|
|
to the directory that you created.
|
|
|
|
|
|
That's it. Run CMake and your new configuration files will be created.
|
|
That's it. Run CMake and your new configuration files will be created.
|
... | @@ -1683,38 +1725,39 @@ That's it. Run CMake and your new configuration files will be created. |
... | @@ -1683,38 +1725,39 @@ That's it. Run CMake and your new configuration files will be created. |
|
Note: Editing the \*Header.dsptemplates files should be done very
|
|
Note: Editing the \*Header.dsptemplates files should be done very
|
|
carefully. Here are some guidelines:
|
|
carefully. Here are some guidelines:
|
|
|
|
|
|
\- You MUST remove the targets that you do not want in your set at the
|
|
- You *must* remove the targets that you do not want in your set at the
|
|
bottom of the file (e.g. '\# Name "OUTPUT_LIBNAME - Win32 MinSizeRel"')
|
|
bottom of the file (e.g. `\# Name "OUTPUT_LIBNAME - Win32 MinSizeRel"`)
|
|
- You can remove the '\!IF "$(CFG)" == ...' until '\!ELSEIF "$(CFG)" ==
|
|
- You can remove the `\!IF "$(CFG)" == ...` until `\!ELSEIF "$(CFG)" == ...`
|
|
...' or '\!ELSEIF "$(CFG)" == ...' until '\!ENDIF' lines for the
|
|
or `\!ELSEIF "$(CFG)" == ...` until `\!ENDIF` lines for the
|
|
configurations you do not want. Make sure that the resulting code still
|
|
configurations you do not want. Make sure that the resulting code still
|
|
starts with '\!IF ...' and ends with '\!ENDIF' with any number of
|
|
starts with `\!IF ...` and ends with `\!ENDIF` with any number of
|
|
'\!ELSEIF' sections in between. If you create templates for a single
|
|
`\!ELSEIF` sections in between. If you create templates for a single
|
|
configuration (aka makefile), it is possible to remove everything
|
|
configuration (aka makefile), it is possible to remove everything
|
|
starting from '\!IF' until and including '\!ENDIF' and leave only the
|
|
starting from `\!IF` until and including `\!ENDIF` and leave only the
|
|
contents of the relevant section intact. - Do not edit the lines
|
|
contents of the relevant section intact.
|
|
starting with '\!MESSAGE' as the changes may - and probably will -
|
|
- Do not edit the lines starting with `\!MESSAGE` as the changes
|
|
corrupt your resulting DSP files. The only thing I was able to change
|
|
may - and probably will - corrupt your resulting DSP files.
|
|
without corrupting the DSP is to remove the irrevant configurations from
|
|
The only thing I was able to change
|
|
the "Possible choices for configuration are:" list.
|
|
without corrupting the DSP is to remove the irrevant configurations from
|
|
|
|
the "Possible choices for configuration are:" list.
|
|
|
|
|
|
If you have only a single configuration in your set, you may want to get
|
|
If you have only a single configuration in your set, you may want to get
|
|
rid of the intermediate dir that MsDev creates. You can do that by
|
|
rid of the intermediate dir that MsDev creates. You can do that by
|
|
setting:
|
|
setting:
|
|
|
|
|
|
1. PROP BASE Output_Dir ""
|
|
1. `PROP BASE Output_Dir ""`
|
|
2. PROP BASE Intermediate_Dir ""
|
|
2. `PROP BASE Intermediate_Dir ""`
|
|
3. PROP Intermediate_Dir ""
|
|
3. `PROP Intermediate_Dir ""`
|
|
4. PROP Output_Dir "LIBRARY_OUTPUT_PATH"
|
|
4. `PROP Output_Dir "LIBRARY_OUTPUT_PATH"`
|
|
|
|
|
|
or
|
|
or
|
|
|
|
|
|
1. PROP Output_Dir "EXECUTABLE_OUTPUT_PATH"
|
|
1. `PROP Output_Dir "EXECUTABLE_OUTPUT_PATH"`
|
|
|
|
|
|
Additionally you should then also edit the '\# ADD LINK32' line in the
|
|
Additionally you should then also edit the `\# ADD LINK32` line in the
|
|
DLLHeader.dsptemplate file. Change for example
|
|
DLLHeader.dsptemplate file. Change for example
|
|
'/out:"LIBRARY_OUTPUT_PATHDebug/OUTPUT_LIBNAMEDEBUG_POSTFIX.dll"'
|
|
`/out:"LIBRARY_OUTPUT_PATHDebug/OUTPUT_LIBNAMEDEBUG_POSTFIX.dll"`
|
|
into '/out:"LIBRARY_OUTPUT_PATHOUTPUT_LIBNAMEDEBUG_POSTFIX.dll"'
|
|
into `/out:"LIBRARY_OUTPUT_PATHOUTPUT_LIBNAMEDEBUG_POSTFIX.dll"`
|
|
(Note that the configuration name and also the slash are removed).
|
|
(Note that the configuration name and also the slash are removed).
|
|
|
|
|
|
It is even possible to rename the pre-defined configurations of CMake in
|
|
It is even possible to rename the pre-defined configurations of CMake in
|
... | @@ -1733,8 +1776,7 @@ partial check on the build type. It will match all configuration types |
... | @@ -1733,8 +1776,7 @@ partial check on the build type. It will match all configuration types |
|
that CONTAIN the build type in their name. (e.g. if you have renamed
|
|
that CONTAIN the build type in their name. (e.g. if you have renamed
|
|
RelWithDebInfo to DebugRelease, Debug will build Debug and DebugRelease,
|
|
RelWithDebInfo to DebugRelease, Debug will build Debug and DebugRelease,
|
|
Release will build Release and DebugRelease. This may be exactly what
|
|
Release will build Release and DebugRelease. This may be exactly what
|
|
you want, but be
|
|
you want, but be warned.)
|
|
warned.)
|
|
|
|
|
|
|
|
### Can CMake set the Debugging/Working Directory property in Visual Studio projects?
|
|
### Can CMake set the Debugging/Working Directory property in Visual Studio projects?
|
|
|
|
|
... | @@ -1782,86 +1824,88 @@ shells this can be fixed by setting an environment variable such as |
... | @@ -1782,86 +1824,88 @@ shells this can be fixed by setting an environment variable such as |
|
`ARG_MAX` to extend the length of the command line it will allow.
|
|
`ARG_MAX` to extend the length of the command line it will allow.
|
|
|
|
|
|
The error can also happen when linking shared libraries, and can be
|
|
The error can also happen when linking shared libraries, and can be
|
|
solved by upping the sysconf parameter MAX_ARG.
|
|
solved by upping the sysconf parameter `MAX_ARG`.
|
|
|
|
|
|
On AIX this can be done with the command:
|
|
On AIX this can be done with the command:
|
|
|
|
```shell
|
|
chdev -l sys0 -a ncargs='30'
|
|
chdev -l sys0 -a ncargs='30'
|
|
|
|
```
|
|
Obviously an alternative approach might be to contemplate reducing the
|
|
Obviously an alternative approach might be to contemplate reducing the
|
|
object count by splitting off some suitable group of objects into their
|
|
object count by splitting off some suitable group of objects into their
|
|
separate static
|
|
separate static library.
|
|
library.
|
|
|
|
|
|
|
|
### How can I find out platforms definitions, search paths, etc. from gcc ?
|
|
### How can I find out platforms definitions, search paths, etc. from gcc ?
|
|
|
|
|
|
The following is really the best if not only way to get information
|
|
The following is really the best if not only way to get information
|
|
about predefined macros with a GNU compiler:
|
|
about predefined macros with a GNU compiler:
|
|
|
|
```shell
|
|
$ touch empty.c
|
|
touch empty.c
|
|
$ gcc -v -dD -E empty.c
|
|
gcc -v -dD -E empty.c
|
|
|
|
```
|
|
|
|
|
|
This will give you all you might want to know about the preprocessor,
|
|
This will give you all you might want to know about the preprocessor,
|
|
the builtin include search dirs and all predefined definitions, so you
|
|
the builtin include search dirs and all predefined definitions, so you
|
|
can check whether it's __LINUX or _LINUX_ or _APPLE_ or __APPLE
|
|
can check whether it's `__LINUX` or `_LINUX_` or `_APPLE_` or `__APPLE`
|
|
etc. The empty file and all these parameters are really required. You
|
|
etc. The empty file and all these parameters are really required. You
|
|
probably want to redirect the output (both stdout and stderr) to a file.
|
|
probably want to redirect the output (both stdout and stderr) to a file.
|
|
If you want the information for C++, use a C++ file suffix for the empty
|
|
If you want the information for C++, use a C++ file suffix for the empty
|
|
file.
|
|
file.
|
|
|
|
|
|
This is how you can get the builtin library search paths:
|
|
This is how you can get the builtin library search paths:
|
|
|
|
```shell
|
|
$ gcc --print-search-dirs
|
|
gcc --print-search-dirs
|
|
|
|
```
|
|
|
|
|
|
### How can I get a windows registry key ?
|
|
### How can I get a windows registry key ?
|
|
|
|
|
|
The only thing to know is that you can't use just the "SET" command in
|
|
The only thing to know is that you can't use just the `set` command in
|
|
place of "GET" command. CMake read the value from the registry only when
|
|
place of `get_` command. CMake read the value from the registry only when
|
|
you "get" it from the cache. For instance
|
|
you "get" it from the cache. For instance:
|
|
:
|
|
```cmake
|
|
|
|
get_filename_component(SDK_ROOT_PATH "[HKEY_LOCAL_MACHINE\\SOFTWARE\\PACKAGE;Install_Dir]" ABSOLUTE CACHE)
|
|
GET_FILENAME_COMPONENT(SDK_ROOT_PATH "[HKEY_LOCAL_MACHINE\\SOFTWARE\\PACKAGE;Install_Dir]" ABSOLUTE CACHE)
|
|
```
|
|
|
|
|
|
If a key name (ex: Install_Dir in this case) was not specified , the
|
|
If a key name (ex: Install_Dir in this case) was not specified , the
|
|
Default key value will be get. Now you could use the SDK_ROOT_PATH to
|
|
Default key value will be get. Now you could use the `SDK_ROOT_PATH` to
|
|
add include and lib path to your project :
|
|
add include and lib path to your project:
|
|
|
|
```cmake
|
|
INCLUDE_DIRECTORIES(
|
|
include_directories(
|
|
${SDK_ROOT_PATH}/include
|
|
${SDK_ROOT_PATH}/include
|
|
)
|
|
)
|
|
|
|
|
|
LINK_DIRECTORIES(
|
|
link_directories(
|
|
${SDK_ROOT_PATH}/lib
|
|
${SDK_ROOT_PATH}/lib
|
|
)
|
|
)
|
|
|
|
```
|
|
|
|
|
|
You can also read a registry key in the PATHS section of a
|
|
You can also read a registry key in the PATHS section of a
|
|
FIND_LIBRARY, FIND_PATH, FIND_PROGRAM, or FIND_FILE
|
|
`find_library`, `find_path`, `find_program`, or `find_file` command:
|
|
command
|
|
```cmake
|
|
|
|
find_file(BOOT_DOT_INI boot.ini PATHS [HKEY_CURRENT_USER\\Environment;HOMEDRIVE])
|
|
FIND_FILE(BOOT_DOT_INI boot.ini PATHS [HKEY_CURRENT_USER\\Environment;HOMEDRIVE])
|
|
```
|
|
|
|
|
|
For other examples have a look in the CMake Modules folder :
|
|
For other examples have a look in the CMake Modules folder :
|
|
|
|
|
|
- FindJava.cmake
|
|
- FindJava.cmake
|
|
- FindPythonLibs.cmake
|
|
- FindPythonLibs.cmake
|
|
- ..
|
|
- ..
|
|
|
|
|
|
### How can I build my MSVC application with a static runtime?
|
|
### How can I build my MSVC application with a static runtime?
|
|
|
|
|
|
Here are three options you could employ to compile your MSVC application
|
|
Here are three options you could employ to compile your MSVC application
|
|
with /MT instead of /MD.
|
|
with `/MT` instead of `/MD`.
|
|
|
|
|
|
#### Manual Replace
|
|
#### Manual Replace
|
|
|
|
|
|
You can rely on the user to manually modify CMAKE_C_FLAGS_DEBUG,
|
|
You can rely on the user to manually modify `CMAKE_C_FLAGS_DEBUG`,
|
|
CMAKE_C_FLAGS_RELEASE, CMAKE_CXX_FLAGS_DEBUG,
|
|
`CMAKE_C_FLAGS_RELEASE`, `CMAKE_CXX_FLAGS_DEBUG`,
|
|
CMAKE_CXX_FLAGS_RELEASE, etc. within the cache editor. After an
|
|
`CMAKE_CXX_FLAGS_RELEASE`, etc. within the cache editor. After an
|
|
initial configure of your software they would have to replace /MD
|
|
initial configure of your software they would have to replace `/MD`
|
|
entries with /MT.
|
|
entries with `/MT`.
|
|
|
|
|
|
#### Make Override Files
|
|
#### Make Override Files
|
|
|
|
|
|
If you intend to build the entire source tree using /MT and you don't
|
|
If you intend to build the entire source tree using `/MT` and you don't
|
|
need this ever to be configurable via the CMake GUI, the best approach
|
|
need this ever to be configurable via the CMake GUI, the best approach
|
|
is to create an override file which initializes the starting cache
|
|
is to create an override file which initializes the starting cache
|
|
values for the compile flags.
|
|
values for the compile flags.
|
... | @@ -1869,52 +1913,57 @@ values for the compile flags. |
... | @@ -1869,52 +1913,57 @@ values for the compile flags. |
|
First create a c_flag_overrides.cmake & cxx_flag_overrides.cmake
|
|
First create a c_flag_overrides.cmake & cxx_flag_overrides.cmake
|
|
file which contain something like this... (or whatever flags you wish to
|
|
file which contain something like this... (or whatever flags you wish to
|
|
use per compiler).
|
|
use per compiler).
|
|
|
|
```cmake
|
|
|
|
# c_flag_overrides.cmake
|
|
|
|
if(MSVC)
|
|
|
|
set(CMAKE_C_FLAGS_DEBUG_INIT "/D_DEBUG /MTd /Zi /Ob0 /Od /RTC1")
|
|
|
|
set(CMAKE_C_FLAGS_MINSIZEREL_INIT "/MT /O1 /Ob1 /D NDEBUG")
|
|
|
|
set(CMAKE_C_FLAGS_RELEASE_INIT "/MT /O2 /Ob2 /D NDEBUG")
|
|
|
|
set(CMAKE_C_FLAGS_RELWITHDEBINFO_INIT "/MT /Zi /O2 /Ob1 /D NDEBUG")
|
|
|
|
endif()
|
|
|
|
|
|
c_flag_overrides.cmake
|
|
```cmake
|
|
if(MSVC)
|
|
# cxx_flag_overrides.cmake
|
|
set(CMAKE_C_FLAGS_DEBUG_INIT "/D_DEBUG /MTd /Zi /Ob0 /Od /RTC1")
|
|
if(MSVC)
|
|
set(CMAKE_C_FLAGS_MINSIZEREL_INIT "/MT /O1 /Ob1 /D NDEBUG")
|
|
set(CMAKE_CXX_FLAGS_DEBUG_INIT "/D_DEBUG /MTd /Zi /Ob0 /Od /RTC1")
|
|
set(CMAKE_C_FLAGS_RELEASE_INIT "/MT /O2 /Ob2 /D NDEBUG")
|
|
set(CMAKE_CXX_FLAGS_MINSIZEREL_INIT "/MT /O1 /Ob1 /D NDEBUG")
|
|
set(CMAKE_C_FLAGS_RELWITHDEBINFO_INIT "/MT /Zi /O2 /Ob1 /D NDEBUG")
|
|
set(CMAKE_CXX_FLAGS_RELEASE_INIT "/MT /O2 /Ob2 /D NDEBUG")
|
|
endif()
|
|
set(CMAKE_CXX_FLAGS_RELWITHDEBINFO_INIT "/MT /Zi /O2 /Ob1 /D NDEBUG")
|
|
|
|
endif()
|
|
cxx_flag_overrides.cmake
|
|
```
|
|
if(MSVC)
|
|
|
|
set(CMAKE_CXX_FLAGS_DEBUG_INIT "/D_DEBUG /MTd /Zi /Ob0 /Od /RTC1")
|
|
|
|
set(CMAKE_CXX_FLAGS_MINSIZEREL_INIT "/MT /O1 /Ob1 /D NDEBUG")
|
|
|
|
set(CMAKE_CXX_FLAGS_RELEASE_INIT "/MT /O2 /Ob2 /D NDEBUG")
|
|
|
|
set(CMAKE_CXX_FLAGS_RELWITHDEBINFO_INIT "/MT /Zi /O2 /Ob1 /D NDEBUG")
|
|
|
|
endif()
|
|
|
|
|
|
|
|
**NOTE:** These files are only evaluated on the first run of CMake so
|
|
**NOTE:** These files are only evaluated on the first run of CMake so
|
|
they can't be dependent on a CMake option() meant to be toggled from the
|
|
they can't be dependent on a CMake option() meant to be toggled from the
|
|
GUI, for example. They could be dependent on a command line -D option or
|
|
GUI, for example. They could be dependent on a command line -D option or
|
|
an environment variable if desired.
|
|
an environment variable if desired.
|
|
|
|
|
|
Then enable them by setting the following variables prior to the
|
|
Then enable them by setting the following variables prior to the
|
|
project() command.
|
|
`project()` command.
|
|
|
|
|
|
set(CMAKE_USER_MAKE_RULES_OVERRIDE
|
|
```cmake
|
|
${CMAKE_CURRENT_SOURCE_DIR}/c_flag_overrides.cmake)
|
|
set(CMAKE_USER_MAKE_RULES_OVERRIDE
|
|
set(CMAKE_USER_MAKE_RULES_OVERRIDE_CXX
|
|
${CMAKE_CURRENT_SOURCE_DIR}/c_flag_overrides.cmake)
|
|
${CMAKE_CURRENT_SOURCE_DIR}/cxx_flag_overrides.cmake)
|
|
set(CMAKE_USER_MAKE_RULES_OVERRIDE_CXX
|
|
project(Bar)
|
|
${CMAKE_CURRENT_SOURCE_DIR}/cxx_flag_overrides.cmake)
|
|
|
|
project(Bar)
|
|
|
|
```
|
|
|
|
|
|
#### Dynamic Replace
|
|
#### Dynamic Replace
|
|
|
|
|
|
Alternatively, if you need dynamic control of /MT via some configure
|
|
Alternatively, if you need dynamic control of `/MT` via some configure
|
|
option you could use the following technique. Note:
|
|
option you could use the following technique. Note:
|
|
CMAKE_CXX_FLAGS_<FOO> is a directory level option, however. Also,
|
|
`CMAKE_CXX_FLAGS_<FOO>` is a directory level option, however. Also,
|
|
this option has the downside of leaving /MD visible in the cache editor
|
|
this option has the downside of leaving `/MD` visible in the cache editor
|
|
although it has no effect.
|
|
although it has no effect.
|
|
|
|
|
|
foreach(flag_var
|
|
```cmake
|
|
CMAKE_CXX_FLAGS CMAKE_CXX_FLAGS_DEBUG CMAKE_CXX_FLAGS_RELEASE
|
|
foreach(flag_var
|
|
CMAKE_CXX_FLAGS_MINSIZEREL CMAKE_CXX_FLAGS_RELWITHDEBINFO)
|
|
CMAKE_CXX_FLAGS CMAKE_CXX_FLAGS_DEBUG CMAKE_CXX_FLAGS_RELEASE
|
|
if(${flag_var} MATCHES "/MD")
|
|
CMAKE_CXX_FLAGS_MINSIZEREL CMAKE_CXX_FLAGS_RELWITHDEBINFO)
|
|
string(REGEX REPLACE "/MD" "/MT" ${flag_var} "${${flag_var}}")
|
|
if(${flag_var} MATCHES "/MD")
|
|
endif(${flag_var} MATCHES "/MD")
|
|
string(REGEX REPLACE "/MD" "/MT" ${flag_var} "${${flag_var}}")
|
|
endforeach(flag_var)
|
|
endif()
|
|
|
|
endforeach()
|
|
|
|
```
|
|
|
|
|
|
### Why do generated Xcode projects have a CMake PostBuild Rules phase?
|
|
### Why do generated Xcode projects have a CMake PostBuild Rules phase?
|
|
|
|
|
... | @@ -1922,9 +1971,9 @@ CMake needs precise control over target link command lines that Xcode |
... | @@ -1922,9 +1971,9 @@ CMake needs precise control over target link command lines that Xcode |
|
runs at build time. Xcode provides a "Link Binary With Libraries" build
|
|
runs at build time. Xcode provides a "Link Binary With Libraries" build
|
|
phase in which one may list files or products from other targets to
|
|
phase in which one may list files or products from other targets to
|
|
include when linking. However, it does not allow arbitrary flags such as
|
|
include when linking. However, it does not allow arbitrary flags such as
|
|
"`-lfoo`" commonly passed by projects to CMake's `target_link_libraries`
|
|
`-lfoo` commonly passed by projects to CMake's `target_link_libraries`
|
|
command. It also does not allow *full* paths to library files and
|
|
command. It also does not allow *full* paths to library files and
|
|
instead splits /path/to/libfoo.a into -L/path/to and -lfoo which does
|
|
instead splits `/path/to/libfoo.a` into `-L/path/to` and `-lfoo` which does
|
|
not guarantee the proper library will be found.
|
|
not guarantee the proper library will be found.
|
|
|
|
|
|
CMake works around this limitation by putting the entire link line in
|
|
CMake works around this limitation by putting the entire link line in
|
... | @@ -1955,8 +2004,7 @@ dependencies on files they mention in |
... | @@ -1955,8 +2004,7 @@ dependencies on files they mention in |
|
|
|
|
|
Xcode 4.3 and later do not install the command-line development tools by
|
|
Xcode 4.3 and later do not install the command-line development tools by
|
|
default. One must also install the "Command Line Tools for Xcode"
|
|
default. One must also install the "Command Line Tools for Xcode"
|
|
package. As of Xcode 4.4 one may install it from the Xcode
|
|
package. As of Xcode 4.4 one may install it from the Xcode menu:
|
|
menu:
|
|
|
|
|
|
|
|
Xcode -> Preferences -> Downloads -> Components -> Command Line Tools
|
|
Xcode -> Preferences -> Downloads -> Components -> Command Line Tools
|
|
|
|
|
... | @@ -1969,23 +2017,26 @@ It is also possible to set up a shell environment to run "cmake" and |
... | @@ -1969,23 +2017,26 @@ It is also possible to set up a shell environment to run "cmake" and |
|
CMake 2.8.10 and greater will recognize when the command-line tools are
|
|
CMake 2.8.10 and greater will recognize when the command-line tools are
|
|
not installed, find the MacOSX SDK, and add the "-isysroot" flag. One
|
|
not installed, find the MacOSX SDK, and add the "-isysroot" flag. One
|
|
may use the environment:
|
|
may use the environment:
|
|
|
|
```shell
|
|
export PATH="$(dirname $(xcrun --find make)):$PATH"
|
|
export PATH="$(dirname $(xcrun --find make)):$PATH"
|
|
export CC="$(xcrun --find cc)"
|
|
export CC="$(xcrun --find cc)"
|
|
export CXX="$(xcrun --find c++)"
|
|
export CXX="$(xcrun --find c++)"
|
|
|
|
```
|
|
|
|
|
|
The above environment will work with CMake 2.8.8 and 2.8.9 if one also
|
|
The above environment will work with CMake 2.8.8 and 2.8.9 if one also
|
|
specifies architectures explicitly (earlier CMake versions are not aware
|
|
specifies architectures explicitly (earlier CMake versions are not aware
|
|
of Xcode 4.3+ SDKs):
|
|
of Xcode 4.3+ SDKs):
|
|
|
|
```shell
|
|
|
|
export CMAKE_OSX_ARCHITECTURES=x86_64
|
|
|
|
```
|
|
|
|
|
|
export CMAKE_OSX_ARCHITECTURES=x86_64
|
|
Alternatively one may add `-isysroot` flags via the environment:
|
|
|
|
```shell
|
|
Alternatively one may add "-isysroot" flags via the environment:
|
|
SDK="$(xcodebuild -sdk macosx -version Path)" &&
|
|
|
|
export CFLAGS="-isysroot $SDK" &&
|
|
SDK="$(xcodebuild -sdk macosx -version Path)" &&
|
|
export CXXFLAGS="-isysroot $SDK" &&
|
|
export CFLAGS="-isysroot $SDK" &&
|
|
unset SDK
|
|
export CXXFLAGS="-isysroot $SDK" &&
|
|
```
|
|
unset SDK
|
|
|
|
|
|
|
|
## Other Questions
|
|
## Other Questions
|
|
|
|
|
... | @@ -1993,9 +2044,9 @@ Alternatively one may add "-isysroot" flags via the environment: |
... | @@ -1993,9 +2044,9 @@ Alternatively one may add "-isysroot" flags via the environment: |
|
|
|
|
|
This question is often asked with reference to this paper:
|
|
This question is often asked with reference to this paper:
|
|
|
|
|
|
- Miller, Peter A., [Recursive Make Considered
|
|
- Miller, Peter A., [Recursive Make Considered
|
|
Harmful](http://miller.emu.id.au/pmiller/books/rmch/), AUUGN Journal
|
|
Harmful](http://miller.emu.id.au/pmiller/books/rmch/), AUUGN Journal
|
|
of AUUG Inc., 19(1), pp. 14-25, 1998
|
|
of AUUG Inc., 19(1), pp. 14-25, 1998
|
|
|
|
|
|
The summary of our response may be worded "recursive make considered
|
|
The summary of our response may be worded "recursive make considered
|
|
necessary". CMake *must* generate makefiles that invoke other makefiles
|
|
necessary". CMake *must* generate makefiles that invoke other makefiles
|
... | @@ -2031,15 +2082,16 @@ worthwhile. |
... | @@ -2031,15 +2082,16 @@ worthwhile. |
|
|
|
|
|
The Makefiles generated by CMake do not support explicit specification
|
|
The Makefiles generated by CMake do not support explicit specification
|
|
of multiple targets on the command line as
|
|
of multiple targets on the command line as
|
|
|
|
```shell
|
|
$ make target1 target2 -j
|
|
make target1 target2 -j
|
|
|
|
```
|
|
|
|
|
|
because it was not a design goal at the time the generators were
|
|
because it was not a design goal at the time the generators were
|
|
written. Insead use
|
|
written. Instead use
|
|
|
|
```shell
|
|
$ make target1 -j && make target2 -j
|
|
make target1 -j && make target2 -j
|
|
|
|
```
|
|
or use add_custom_target and add_dependencies to create a single
|
|
or use `add_custom_target` and `add_dependencies` to create a single
|
|
target depending on both targets and then make that.
|
|
target depending on both targets and then make that.
|
|
|
|
|
|
See the multi-level makefile layout described in the answer to the
|
|
See the multi-level makefile layout described in the answer to the
|
... | @@ -2058,4 +2110,4 @@ solution must work with ancient UNIX make and cannot depend on GNU make |
... | @@ -2058,4 +2110,4 @@ solution must work with ancient UNIX make and cannot depend on GNU make |
|
features.
|
|
features.
|
|
|
|
|
|
----
|
|
----
|
|
This page was initially populated by conversion from its [original location](https://public.kitware.com/Wiki/CMake_FAQ) in another wiki. |
|
This page was initially populated by conversion from its [original location](https://public.kitware.com/Wiki/CMake_FAQ) in another wiki. |
|
|
|
\ No newline at end of file |