I am trying to generate a file, but it fails to resolve variables. Since file(generate) runs during the generate step, are there limitations to what variables it can resolve? (e.g. only cache variables?)
My variables don't get resolved despite them being defined.
message("Registered composites: ${COURAGE_COMPOSITES}")
file(GENERATE OUTPUT ${OUTPUT_PATH}/output.xml INPUT ${INPUT_PATH}/output.xml.in)
output.xml.in
<imports>
$<$<NOT:$<STREQUAL:"${COURAGE_COMPOSITES}","">>:<import iuts="yes"$<ANGLE-R>$<JOIN:${COURAGE_COMPOSITES},</import$<ANGLE-R><import iuts="yes"$<ANGLE-R>></import$<ANGLE-R>>
</imports>
output.xml
<imports>
<import iuts="yes">${COURAGE_COMPOSITES}</import>
</imports>
Actually, file(GENERATE) doesn't expand variables at all.
Documentation for that command tells nothing about variable's expansion
Generate an output file for each build configuration supported by the current CMake Generator. Evaluate generator expressions from the input content to produce the output content.
If you want to expand variables, you could firstly expands them with command configure_file into intermediate file, and then expand generator expressions in that file using file(GENERATE):
# output.xml.in -> output.xml.im
configure_file(${INPUT_PATH}/output.xml.in ${OUTPUT_PATH}/output.xml.im)
# output.xml.im -> output.xml
file(GENERATE OUTPUT ${OUTPUT_PATH}/output.xml INPUT ${OUTPUT_PATH}/output.xml.im)
Alternatively, if your input file is small, you could embed it into the CMakeLists.txt as a string, and use CONTENT parameter for file(GENERATE):
file(GENERATE OUTPUT ${OUTPUT_PATH}/output.xml CONTENT
[=[
<imports>
$<$<NOT:$<STREQUAL:"${COURAGE_COMPOSITES}","">>:<import iuts="yes"$<ANGLE-R>$<JOIN:${COURAGE_COMPOSITES},</import$<ANGLE-R><import iuts="yes"$<ANGLE-R>></import$<ANGLE-R>>
</imports>
]=]
)
In that case the variable substitution will be performed by CMake itself before it passes the string to the command.
Related
In the build process, I set directories where I gather the build output of different sub-projects. The directories are set as :
set( CMAKE_RUNTIME_OUTPUT_DIRECTORY_DEBUG "${CMAKE_CURRENT_LIST_DIR}/../build/bin/debug" )
set( CMAKE_RUNTIME_OUTPUT_DIRECTORY_RELEASE "${CMAKE_CURRENT_LIST_DIR}/../build/bin/release" )
Now, I'd like to copy some files (a directory of qt plugins) to that directory dependent on the configuration which it is built for.
I tried:
# copy qt plugins
add_custom_command( TARGET mytarget POST_BUILD
COMMAND ${CMAKE_COMMAND} -E copy_directory
"${QT_DIR}/../../../plugins"
"${$<UPPER_CASE:CMAKE_RUNTIME_OUTPUT_DIRECTORY_$<CONFIG> >}/plugins"
COMMAND_EXPAND_LISTS)
thus, I try to build a string that equals the variable name and then try to expand that as described here: CMake interpret string as variable. In other words: I would like to have a generator expression that evaluates to the content of CMAKE_RUNTIME_OUTPUT_DIRECTORY_DEBUG or CMAKE_RUNTIME_OUTPUT_DIRECTOR_RELEASE dependent on the current build configuration.
However running cmake with the statement above results in an error:
"CMakeLists.txt:112: error: Syntax error in cmake code at [..] when parsing string ${$<UPPER_CASE:CMAKE_RUNTIME_OUTPUT_DIRECTORY_$<CONFIG> >}/plugins Invalid character ('<') in a variable name: '$'
So my question is, how can I use a generator-expression to access the corresponding variable? (Bonus question: is there another/better way to achieve the same goal?)
So my question is, how can I use a generator-expression to access the corresponding variable?
You cannot. There is currently (CMake <=3.23) no way to expand a variable whose name is determined by the value of a generator expression.
Bonus question: is there another/better way to achieve the same goal?
Yes, and you are almost there! You can use $<TARGET_FILE_DIR:...>:
add_custom_command(
TARGET mytarget POST_BUILD
COMMAND
${CMAKE_COMMAND} -E copy_directory
"${QT_DIR}/../../../plugins"
"$<TARGET_FILE_DIR:mytarget>/plugins"
VERBATIM
)
This works because TARGET_FILE_DIR evaluates to the actual directory containing the executable or library file for mytarget, no matter the active configuration, property values, etc.
Docs: https://cmake.org/cmake/help/latest/manual/cmake-generator-expressions.7.html#genex:TARGET_FILE_DIR
CMAKE_RUNTIME_OUTPUT_DIRECTORY_<CONFIG> is already relative to the binary directory so you should not try to compute the binary directory in its definition. Also, it supports generator expressions. Thus, the following will be much more robust:
set(CMAKE_RUNTIME_OUTPUT_DIRECTORY "bin/$<LOWER_CASE:$<CONFIG>>"
CACHE STRING "Common output directory for runtime artifacts")
This has a bunch of concrete benefits:
No need to set CMAKE_RUNTIME_OUTPUT_DIRECTORY_DEBUG or CMAKE_RUNTIME_OUTPUT_DIRECTORY_RELEASE
This will work for MinSizeRel and RelWithDebInfo, plus any custom configurations one might add down the line.
Since it's defined as a cache variable, it can be overridden for debugging / working around name clashes, etc.
A bit more context for (3): most CMAKE_* variables are intended to be either read-only or user-configurable (i.e. at the command line, from the GUI, etc.). Overriding their defaults via set(CACHE) is a polite compromise. A notable exception to this rule is the collection of Qt codegen flags (CMAKE_AUTO{MOC,RCC,UIC}). These must typically be set for the build to produce usable binaries.
I have such a requirement. I want to modify my source file according to the configuration file in the cmake stage. Is there a good way?
configure_file command is your friend.
First you create a template file filled with strings line ${MY_VAR} (called foo.ext.in by convention) and then pass into as the argument of configure_file. During configuration step, CMake will generate foo.ext file from your template, substituting any ${VARS} with corresponding values from CMake code scope.
Imagine a code generator which reads an input file (say a UML class diagram) and produces an arbitrary number of source files which I want to be handled in my project. (to draw a simple picture let's assume the code generator just produces .cpp files).
The problem is now the number of files generated depends on the input file and thus is not known when writing the CMakeLists.txt file or even in CMakes configure step. E.g.:
>>> code-gen uml.xml
generate class1.cpp..
generate class2.cpp..
generate class3.cpp..
What's the recommended way to handle generated files in such a case? You could use FILE(GLOB.. ) to collect the file names after running code-gen the first time but this is discouraged because CMake would not know any files on the first run and later it would not recognize when the number of files changes.
I could think of some approaches but I don't know if CMake covers them, e.g.:
(somehow) define a dependency from an input file (uml.xml in my example) to a variable (list with generated file names)
in case the code generator can be convinced to tell which files it generates the output of code-gen could be used to create a list of input file names. (would lead to similar problems but at least I would not have to use GLOB which might collect old files)
just define a custom target which runs the code generator and handles the output files without CMake (don't like this option)
Update: This question targets a similar problem but just asks how to glob generated files which does not address how to re-configure when the input file changes.
Together with Tsyvarev's answer and some more googling I came up with the following CMakeList.txt which does what I want:
project(generated)
cmake_minimum_required(VERSION 3.6)
set(IN_FILE "${CMAKE_SOURCE_DIR}/input.txt")
set_property(DIRECTORY APPEND PROPERTY CMAKE_CONFIGURE_DEPENDS "${IN_FILE}")
execute_process(
COMMAND python3 "${CMAKE_SOURCE_DIR}/code-gen" "${IN_FILE}"
WORKING_DIRECTORY ${PROJECT_BINARY_DIR}
INPUT_FILE "${IN_FILE}"
OUTPUT_VARIABLE GENERATED_FILES
OUTPUT_STRIP_TRAILING_WHITESPACE
)
add_executable(generated main.cpp ${GENERATED_FILES})
It turns an input file (input.txt) into output files using code-gen and compiles them.
execute_process is being executed in the configure step and the set_property() command makes sure CMake is being re-run when the input file changes.
Note: in this example the code-generator must print a CMake-friendly list on stdout which is nice if you can modify the code generator. FILE(GLOB..) would do the trick too but this would for sure lead to problems (e.g. old generated files being compiled, too, colleagues complaining about your code etc.)
PS: I don't like to answer my own questions - If you come up with a nicer or cleaner solution in the next couple of days I'll take yours!
Due to the following warning:
CMake Error at test/CMakeLists.txt:29 (get_target_property):
The LOCATION property may not be read from target "my_exe". Use the
target name directly with add_custom_command, or use the generator
expression $<TARGET_FILE>, as appropriate.
which is the result from lines like this:
get_target_property(my_exe_path my_exe LOCATION)
Like recommended in the docs, I tried to use a generator expression like this:
add_executable(my_exe_path main.cpp)
message("path to executable: $<TARGET_FILE:my_exe_path>")
But TARGET_FILE is not being evaluated
path to executable: $<TARGET_FILE:my_exe>
I'm using CMake 3.4 and added cmake_minimum_required(VERSION 3.4) to my CMakeLists.txt so what am I doing wrong?
Here is a quick and easy way to print the value of a generator expression:
add_custom_target(print
${CMAKE_COMMAND} -E echo $<1:hello> $<0:world>
)
In this example, if you run cmake . and then make print, you will see "hello" (without the quotation marks) in the output.
However, if you just use message($<1:hello> $<0:world>), you will see "$<1:hello> $<0:world>" as output (again, without the quotation marks).
While generator expression is stored at configuration stage (when corresponded CMake command is executed),
evaluation of generator expressions is performed at build stage.
This is why message() command prints generator expression in non-dereferenced form: value denoted by the generator expression is not known at this stage.
Moreover, CMake never dereferences generator expressions by itself. Instead, it generates appropriate string in the build file, which is then interpreted by build utility (make, Visual Studio, etc.).
Note, that not every CMake command accepts generator expressions. Each possible usage of generator expressions is explicitely described in documentation for specific command. Moreover, different CMake command flows or different options have different policy about using of generator expressions.
For example, command flow
add_test(NAME <name> COMMAND <executable>)
accepts generator expressions for COMMAND option,
but command flow
add_test(<name> <executable>)
doesn't!
Another example of policies difference:
install(DIRECTORY <dir> DESTINATION <dest>)
In this command flow generator expressions are allowed for DESTINATION, but not for DIRECTORY option.
Again, read documentation carefully.
Directory prj/test contains some test scripts t01.exe, t02.exe etc. Some of them need input data d01.dat etc, also provided in prj/test. The names of these data files are hard-coded in the tests, and I cannot easily change this. The control file CMakeLists.txt contains
enable_testing()
file(GLOB test_sources "t*")
foreach(test_src ${test_sources})
string(REGEX REPLACE ".*/" "" test_name "${test_src}")
string(REGEX REPLACE ".exe$" "" test_name "${test_name}")
add_test(${test_name} "${test_src}")
endforeach(test_src)
I'm building the project in a subdirectory prj/build. ctest works fine ... until a test requires input data. Obviously, they are not found because they reside in prj/test whereas the test runs in prj/build/test.
Hence my questions:
What's the standard way to let the tests find their input data?
Is there a way that does not require copying the data (in case they are huge)?
True that symlinks don't work under Windows, and therefore are no acceptable solution?
add_test command accepts WORKING_DIRECTORY option. You can set this option to a directory where a test is located. So, the test will find its data file:
add_test(NAME ${test_name} COMMAND "${test_src}"
WORKING_DIRECTORY ${CMAKE_CURRENT_SOURCE_DIR}
)
The variables ${CMAKE_CURRENT_SOURCE_DIR} and ${CMAKE_SOURCE_DIR} are helpful. The first one is the source directory to the current binary location. The latter is the root to the top level of the source tree.
Supposed you have an input file at prj/test/inputfile you could get the path to it with${CMAKE_CURRENT_SOURCE_DIR}/inputfile. You can pass the path as an argument to your test.