My UNIX Makefile is as follows:
param=0
run:
./foo -r "fun($(param))"
So if I do make run, I get ./foo - r "fun(0)" and
for make run param=10, I get ./foo -r "fun(10)".
Now I want to generate similar Makefile using cmake.
add_custom_target(
run
./foo -r "\"fun($(param))\""
)
How do I set the default value for param within cmake configuration file?
The concept in CMake is a bit different. You can define "cache variables" (basically variables that are remembered for subsequent builds in the same build dir, and can be customized by users) that come with default values and documentation strings and such. These can then be changed either by passing -D name:type=value options to cmake, or using one of the friendlier frontends (e.g. ccmake, the curses UI for CMake).
Example based on your question:
SET(param 0 CACHE STRING "Test variable defaulting to '0'")
# ...
add_custom_target(run ./foo -r "\"fun(${param})\"")
You'll find more details in the exhaustive docs for CMake.
PS. this is for variables inside CMake and specifically CMakeLists.txt itself; the possibility to change the value is not carried over into the generated Makefile as far as I can tell. I'm not sure that's possible in the first place because it probably wouldn't be compatiable with all of the targets supported by CMake (e.g. Visual Studio projects and what not). In any case, CMake doesn't seem to have been designed for generating build files used independently of CMake.
Use
set (projectname_param 0)
to set it.
Related
Perhaps I am missing something obvious, but I can't seem to figure out how to explicitly set environment variables that can be seen by processes launched through add_custom_target().
I tried the following:
set(ENV{PATH} "C:/Some/Path;$ENV{PATH}")
add_custom_target(newtarget somecommand)
Unfortunately, the %PATH% environment variable appears unchanged to somecommand. (I have set up a Gist that reproduces the problem here.)
What am I doing wrong?
A portable way of setting environment variables for a custom target is to use CMake's command-line tool mode command env:
env [--unset=NAME]... [NAME=VALUE]... COMMAND [ARG]...
Run command in a modified environment.
E.g.:
add_custom_target(newtarget ${CMAKE_COMMAND} -E env NAME=VALUE somecommand)
Also see Command Line Tool Mode.
You set environment variable at configuration step, but command specified for add_custom_target is executed at build step. See also CMake FAQ: How can I get or set environment variables?
[...]
environment variables SET in the CMakeLists.txt only
take effect for cmake itself (configure-time),
so you cannot use this method to set an environment variable
that a custom command might need (build-time).
Barring environment variable support by various CMake commands
(e.g. add_custom_command(), currently not supported yet),
an acceptable workaround may be to invoke shell scripts instead
which wrap the commands to be executed.
Currently add_custom_target (and others commands, which define actions for build step, e.g. add_custom_command) doesn't support simple setting environment variables. As adviced in this bugreport, for set variable's value without spaces on Linux you may prepend command with "VAR=VAL" clauses. For general cases you may prepare wrapper script, which setups environment and run actual command:
On Windows:
wrapper.bat:
#ECHO OFF
set PATH=C:\\Some\\Path;%PATH%
%*
CMakeLists.txt:
add_custom_target(...
COMMAND cmd /c ${CMAKE_CURRENT_SOURCE_DIR}/wrapper.bat <real_command> args...
)
On Linux:
wrapper.sh:
export "PATH=/Some/Path:$PATH"
eval "$*"
CMakeLists.txt:
add_custom_target(...
COMMAND /bin/sh ${CMAKE_CURRENT_SOURCE_DIR}/wrapper.sh <real_command> args...
)
If value of variable depends on configuration, you may configure wrapper script with configure_file.
UPDATE:
As noted by #sakra, env tool mode of cmake executable can be used as a wrapper script:
add_custom_target(...
COMMAND ${CMAKE_COMMAND} -E env "PATH=C:/Some/Path;$ENV{PATH}" <real_command> args...
)
This way is available since CMake 3.2.
A late answer to this, but perhaps it will help somebody. We use the && operator to do this in our cmake files on Windows.
set(MY_COMMAND set "PATH=C:\\some\\path\;%PATH%"&&
somecommand)
add_custom_target(TARGET newtarget COMMAND ${MY_COMMAND})
Note that you cannot have a space before the && (for reasons I don't understand completely). Also, spaces are a real pain to deal with here, so I don't know if I have it right if c:\some\path has spaces. It does work if your original path has spaces.
The command works for me
add_custom_target(
run
DEPENDS ${PROJECT_NAME}
COMMAND ASAN_OPTIONS=alloc_dealloc_mismatch=0 ./${PROJECT_NAME}
)
Is that true that you can't customize the name of your CMakeLists.txt file? I read in a few places that make suffers from the same problem, but that's completely not true, you sure can:
~$ make -f whatever_name_you_feel_like
Can't you do this with CMake?
My situation is as follows: The project leader wants to have a certain CMakeLists.txt file run in the CI workflow and another when developing. I thought it would be possible to just keep 2 CMake files and tell cmake which one to execute.
It's not possible to use file with a name different to CMakeLists.txt, but I'm almost certain that's not actually what you want to do anyways.
I assume the cl version and the development version are mostly similar and only some details change. In this case you should not duplicate the logic. Instead add one or multiple options to your cmake project that can set when you set up the build dir and can even be changed without reconfiguring the whole project from scratch. Basically you add a cache variable to CMakeLists.txt which allows the user to overwrite the default value via -D command line option. The value can also be modified after the initial configuration using cmake-gui.
cmake_mimimum_required(VERSION 3.0.2)
project(MyProject)
# option set to true by default
set(MY_PROJECT_COMMAND_LINE_BUILD 1 CACHE BOOL "Use the command line configuration for MyProject")
#logic common to both configurations
add_executable(MyProg foo.cpp bar.cpp)
if(MY_PROJECT_COMMAND_LINE_BUILD)
#logic only for command line build
target_compile_definitions(MyProg PRIVATE COMMAND_LINE_BUILD)
else()
# logic only for non-command line build
target_compile_definitions(MyProg PRIVATE DEVELOPMENT_BUILD)
endif()
Ironically you could set up both from the command line:
Command line build
cmake -S sourceDir -B buildDir
Development build
cmake -D MY_PROJECT_COMMAND_LINE_BUILD:BOOL=0 -S sourceDir -B buildDir
If you don't want to enter the cache values in the command line every time you set up the project, you could also use a cmake script file to initialize the cache values using the -C command line option.
cmake -C developmentVersion.cmake -S sourceDir -B buildDir
developmentVersion.cmake:
set(MY_PROJECT_COMMAND_LINE_BUILD 0 CACHE BOOL "Use the command line configuration for MyProject")
Theoretically you could the whole CMakeLists.txt file in an if else endif structure and use include in one of the alternatives to competely replace the standard logic in the CMakeLists.txt file, but imho this is not a good idea.
Can't you do this with CMake?
No, it's not possible.
The project leader wants to have a certain CMakeLists.txt file run in the CI workflow and another when developing.
One way: copy or symlink proper CMakeLists.txt before executing cmake.
Preferably one would use cmake scripting language:
# CMakeLists.txt
if (MODE STREUQAL "CI_WORKFLOW")
include(CMakeLists-ci-workflow.txt)
elseif (MODE STREQUAL "DEVELOPING")
include(CMakeLists-developing.txt)
else()
message("SUPER ERROR")
fi()
and then separate CMakeLists-ci-workflow.txt and separate CMakeLists-developing.txt and do cmake -D MODE=DEVELOPING or -D MODE=CI_WORKFLOW.
But overall, the idea of "separate CMakeLists.txt" sounds bad to me. Instead use CMAKE_BUILD_TYPE=Debug for developing and CMAKE_BUILD_TYPE=Release for release builds, and use other cmake variables to differentiate settings, instead of duplicating configuration.
There are several settings I need to provide to CMake which are the same on every project. It gets annoying having to specify these on the command line every time I blow away my build area and start again.
For example:
cmake .. -DCMAKE_BUILD_TYPE=Debug -DCMAKE_INSTALL_PREFIX=${HOME}/local
Is there a way to provide values for common settings like CMAKE_BUILD_TYPE and CMAKE_INSTALL_PREFIX so that they are applied to all projects by default?
You may create "initial-cache" script
~/default.cmake:
set(CMAKE_BUILD_TYPE Debug CACHE STRING "Build type")
set(CMAKE_INSTALL_PREFIX $ENV{HOME}/local CACHE PATH "Installation prefix")
and pass it to cmake as with -C option:
cmake -C ~/default.cmake ..
More info about -C option in cmake(1) documentation.
As for using these setting by default (that is, without any additional options to cmake), I don't know a clear way for doing this.
You may create wrapper script like default-cmake, which calls cmake with original plus additional parameters.
Another way is to create an initial CMakeCache.txt file that exactly contains those two variables:
$ cat CMakeCache.txt
CMAKE_BUILD_TYPE:STRING=Debug
CMAKE_INSTALL_PREFIX:PATH=~/local
Upon the next cmake run, the CMakeCache.txt will contains the remaining of the cmake run. You do not need to pass any additional flags to cmake, but it will scratch your inital CMakeCache.txt (thus you need to add it to .gitignore).
I'm in a cmake build directory and want to build the project, but don't know if cmake was run with -G Unix\ Makefile or -G Ninja.
Now I know I can just be ignorant of that and use cmake --build ., but when I want to provide additional options cmake --build . -- SOMETHING I should know if I should provide gnumake or ninja options.
As possible solutions I found that I can just check the presence of a Makefile or build.ninja file. Or grep in the CMakeCache.txt for CMAKE_GENERATOR.
EDIT:
In a similar question here it is explained that values passed to cmake with -D can be queried with cmake -LA -N. But this doesn't list the -G parameter.
I am wondering if there is a more proper way (just like cmake -LA -N instead of grepping for variable values).
You've cited two possible solutions:
Check presence of build system files. Not a general solution, as it only works for some generators, but it may work in your case. This would not work for Visual Studio (for example, unless you parse the Visual Studio files themselves), as each generator version creates the same filenames.
Grep CMakeCache.txt for CMAKE_GENERATOR. Relies on platform specific tools (grep), and the location of the CMakeCache.txt. Both likely not a problem in most situations.
A slight modification to the second option, which makes it more portable, is to cache the CMAKE_GENERATOR in another variable:
set(USED_CMAKE_GENERATOR "${CMAKE_GENERATOR}" CACHE STRING "Expose CMAKE_GENERATOR" FORCE)
Then, when you use cmake -L, USED_CMAKE_GENERATOR will show up.
I use cmake-gui to configure OpenCV, and I want to use same configure on some other computer.
Cause I use ssh without X forwarding, so I can't use cmake-gui to configure again.
I don't kown how to use cmake to complete my configure, so I wonder that cmake-gui can generate the command use for cmake?
Is there anyway to do this?
There is an option called: Tools-> Show my Changes which displays exactly what you have configured relating to the original configuration. One version are the copy&paste command line parameters and the other version is nicely human readable.
By default you cannot do what you want because that path is stored in CMAKE_COMMAND which is an INTERNAL variable so it is not visible in the GUI. You can manually read it from the cache using a command like grep CMAKE_COMMAND CMakeCache.txt | cut -d = -f 2. Alternatively you can update your CMakeLists.txt to put the value of CMAKE_COMMAND in the cache so that you can read it using the GUI. For example:
set(USED_CMAKE_PATH ${CMAKE_COMMAND} CACHE FILEPATH
"The path to the CMake executable used to configure this project" FORCE)
Additionally if you are using the "Unix Makefiles" generator there are two targets provided for this:
rebuild_cace which is equivalent to cmake .
edit_cache which is equivalent to ccmake . or cmake-gui . depending upon your install.
Note: I used CMake version 2.8.10.2 to test this, but I expect it to work with any version.