Is it possible to set a bunch of variables before they are defined e.g., when using CUDA and I write
SET(MY_CUDA_LIBS CUDA_CUBLAS_LIBRARIES CUDA_CUFFT_LIBRARIES),
such that when are being defined by
FIND_PACKAGE(CUDA REQUIRED)
(CUDA_CUBLAS_LIBRARIES and CUDA_CUFFT_LIBRARIES can now be accessed i.e., ${CUDA_CUBLAS_LIBRARIES} and ${CUDA_CUFFT_LIBRARIES} are the paths to the corresponding library), I can access something like ${MY_CUDA_LIBS} and it returns ${CUDA_CUBLAS_LIBRARIES} ${CUDA_CUFFT_LIBRARIES}?
This obviously works, if I e.g. use CUDA_CUBLAS_LIBRARIES only and do ${${MY_CUDA_LIBS}}, but as soon as one has multiple libraries this trick does not work anymore and it returns CUDA_CUBLAS_LIBRARIESCUDA_CUFFT_LIBRARIES or "nothing".
The idea is to define the CUDA libraries in the very beginning of my CMakeLists.txt and it (far) later automatically inserts the corresponding path when accessed in TARGET_LINK_LIBRARIES.
Technically, you should treat the MY_CUDA_LIBS as a list. Then, the following is possible:
set(MANY_LIBS LIB_1 LIB_2)
set(LIB_1 "/libs/lib1")
set(LIB_2 "/libs/lib2")
list(GET MANY_LIBS 0 PATH)
message(${${PATH}})
list(GET MANY_LIBS 1 PATH)
message(${${PATH}})
resulting in the following output as predicted:
/libs/lib1
/libs/lib2
If you want it to use later in TARGET_LINK_LIBRARIES you probably can do the following after your variable are defined properly:
foreach(libname ${MANY_LIBS})
list(APPEND MANY_LIBS_PATHS ${${libname}})
endforeach(${MANY_LIBS_PATHS})
message("${MANY_LIBS_PATHS}")
after that, MANY_LIBS_PATHS can be used for linking.
Related
Not sure how to perfectly word this from the title, but I am new to CMake and slowly progressing through the online tutorial.
I am up to Step 4 and sometimes find it confusing when mixing passed values that in my eyes are strings, and thus in all programming languages I expect them to have quotation marks or some sort around them. However sometimes I create new targets with the same names. I will elaborate with an example. I reworded some things from the tutorial to make it a bit more clear for me to see what they actually do.
In the root CMakeLists.txt I have this file,
cmake_minimum_required(VERSION 3.10)
project(My_Project VERSION 1.0)
add_library(tutorial_compiler_flags INTERFACE)
target_compile_features(tutorial_compiler_flags INTERFACE cxx_std_11)
option(USE_MYMATH "Use tutorial provided math implementation" TRUE)
configure_file(src/sqrt.h.in src/sqrt.h)
if(USE_MYMATH)
add_subdirectory(MathFunctions)
list(APPEND EXTRA_LIBS MathFunctions)
endif()
add_executable(compute_square_root src/sqrt.cxx)
target_link_libraries(compute_square_root PUBLIC ${EXTRA_LIBS} tutorial_compiler_flags)
target_include_directories(compute_square_root PUBLIC "${PROJECT_BINARY_DIR}/src")
Inside of MathFunctions I have
add_library(MathFunctions mysqrt.cxx)
target_include_directories(MathFunctions INTERFACE ${CMAKE_CURRENT_SOURCE_DIR})
Here is where the confusion can come from. Notice that in
add_subdirectory(MathFunctions)
MathFunctions is kind of treated as a string in my eyes, because it is now looking for the directory current_location/MathFunctions. However inside of of the MathFunctions CMakeLists.txt it now creates a target with the exact same spelling from the line "add_library(MathFunctions mysqrt.cxx)", this is then immediately referenced afterwards from the "target_include_directories(MathFunctions, ...".
Here, target_include_directories is referring to the target MathFunctions we just created. Now, when we leave that CMakeLists.txt we now have another line "list(APPEND EXTRA_LIBS MathFunctions)". Now I some confusion, like, is this MathFunctions referring to the target we just made? Is it a string called "MathFunctions"? In the documentation for target_link_libraries it says that it has to be a target created by add_library so I assume it is referring to the previous add_library(MathFunctions ...) call. I find the scoping weird here too, since we are referring to something that was made from a child, inside a different call.
Do we have certain rules in CMake for this kind of behaviour? THanks
All command parameters are treated as strings in cmake. Parameters are separated by whitespace unless quoted. The exact effect of a parameter depends on the command.
The following commands have the same effect:
add_subdirectory(MathFunctions)
add_subdirectory("MathFunctions")
In the case of add_library the first parameter is treated as the target name. CMake internally keeps track of targets and stores several pieces of information for them. The target name MathFunctions is entirely unrelated to the name of the subdirectory added via add_subdirectory; you could rename the directory to FooBar and use add_subdirectory(FooBar) and nothing would change.
There are several commands you pass the target name to to modify the properties of the cmake target as well as commands that treat the name of cmake targets specially e.g.:
target_include_directories: the target to modify the [INTERFACE_]INCLUDE_DIRECTORIES property for is passed
target_link_directories: the target to modify the [INTERFACE_]LINK_DIRECTORIES property for is passed
set_target_properties: One or more targets to set properties for are passed
target_link_libraries: The cmake target linked to is passed. Furthermore cmake library targets may be specified as libraries to be linked to the target.
add_test: If you use the name of a cmake target in the COMMAND part, the test logic uses the path to the target instead.
...
As for scope:
Variable values you write are actually set for the current scope only, but reading variables cmake looks into ancestor scopes, unless a variable is found in the current scope. CMake targets are visible in the whole cmake project though from the point of the parsing of the command creating the target(add_library, add_executable, add_custom_target): cmake targets are "global objects". (Exceptions exist for imported libs and alias targets, but that's probably nothing relevant to you right now.)
I have multiple targets that are being made in a CMake project. Each target has a different linkscript (LD file). How do I write the CMakeLists.txt file to make this happen? This is for an embedded project with C/C++/ASM files.
This is what I have so far. The problem is that LINKER_SCRIPT is defined globally and not per-target.
# add alpha target
add_executable(alpha.elf ${SOURCES})
target_compile_definitions(alpha.elf PUBLIC -DALPHA_DEFINED)
set(LINKER_SCRIPT ${CMAKE_SOURCE_DIR}/Linker/alpha.ld)
# add beta target
add_executable(beta.elf ${SOURCES})
target_compile_definitions(beta.elf PUBLIC -DBETA_DEFINED)
set(LINKER_SCRIPT ${CMAKE_SOURCE_DIR}/Linker/beta.ld)
set(CMAKE_EXE_LINKER_FLAGS
"${CMAKE_EXE_LINKER_FLAGS} -T ${LINKER_SCRIPT}")
The problem is that LINKER_SCRIPT gets overwritten and the last definition is the one used. How can I make this work?
I have tried to define per-target variable using the following, however the output is not as expected. The file gets compiled, however things are not where they should be. For example, the generated HEX file does not start at 0x08000000 which is where it should be defined per the LD file.
set_target_properties(alpha.elf PROPERTIES
CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} -Wl,-Map=${PROJECT_BINARY_DIR}/alpha.elf.map -T ${CMAKE_SOURCE_DIR}/Linker/alpha.ld")
The variable LINKER_SCRIPT is just being over-ridden the second time you set it to a value. It doesn't have global scope but sub-directory / function scope. But like any variable it takes on its latest value.
CMAKE_EXE_LINKER_FLAGS is being used for both targets in this case. Splitting this into separate sub-directories may work but I've never tried it.
There are no per-target variables that I am aware of. set_target_properties is used to set properties. Some properties are known to CMake, but the property CMAKE_EXE_LINKER_FLAGS is not one of them. It should just be ignored when generating the build files.
Try using target_link_options to set per-target property LINK_OPTIONS which is known and the option will show up when linking the executable.
For example target_link_options(alpha.elf PRIVATE -T${CMAKE_SOURCE_DIR}/Linker/alpha.ld). I haven't used it with options that have a space in them so that might be a problem.
To re-link if the linker script changes then refer to this answer:
https://stackoverflow.com/a/42138375/1028434
I'm trying to loop over a list with library names in CMake. In each iteration I search the library with find_library:
set(LIB_NAMES "TKBO;TKBRep;")
set(LIBS_DIR /usr/local/OCCT/7.2.0/libd)
FOREACH(LIB_NAME ${LIB_NAMES})
FIND_LIBRARY(LIB ${LIB_NAME} PATHS ${LIBS_DIR})
MESSAGE("<<${LIB_NAME}>>")
MESSAGE("<<${LIB}>>")
target_link_libraries(mySharedLib ${LIB})
ENDFOREACH()
For the above, I get the output:
<<TKBO>>
<</usr/local/OCCT/7.2.0/libd/libTKBO.dylib>>
<<TKBRep>>
<</usr/local/OCCT/7.2.0/libd/libTKBO.dylib>>
While LIB_NAME updates, FIND_LIBRARY seems to be using an outdated value. I also tried to explicitly UNSET(LIB_NAME) at the end of the loop but that didn't help either.
What could I be overlooking?
The result of find_library is a CACHED variable, and once the library is found, the variable is not updated.
When search different libraries, it is better to use different result variables:
FOREACH(LIB_NAME ${LIB_NAMES})
set(LIB_VAR "LIB_${LIB_NAME}") # Name of the variable which stores result of the search
FIND_LIBRARY(${LIB_VAR} ${LIB_NAME} PATHS ${LIBS_DIR})
target_link_libraries(mySharedLib ${${LIB_VAR}})
ENDFOREACH()
Here LIB_TKBO variable is used for TKBO library, and LIB_TKBRep variable - for TKBRep library.
Solved by:
UNSET(LIB_NAME CACHE)
See here for a similar problem.
I can pass defined variable for cmake like below(for example when I want to set PYTHON_INCLUDE_PATH=dir1).
cmake -DPYTHON_INCLUDE_PATH=dir1 ..
But what if I want to set multiple paths for this PYTHON_INCLUDE_PATH? I tried
cmake -DPYTHON_INCLUDE_PATH='dir1 dir2 dir3'
or should it be
cmake -DPYTHON_INCLUDE_PATH='dir1:dir2:dir3' (or , instead of :)
But I'm not sure it's valid. (see some other error so I am not sure yet if it's correct or not.)
I saw I can also set these defines in .cmake file like set(VARIABLE,VALUE) like below.
set(OpenCV_CUDA_VERSION 7.5)
Then what's the corresponding syntax for this set(..) form when the variable has multiple elements?
use the following syntax:
cmake -DLIST_VAR="one;two;three" ...
you can play w/ the following CMakeLists.txt:
cmake_minimum_required(VERSION 3.5)
foreach(v IN LISTS LIST_VAR)
message(STATUS "${v}")
endforeach()
I used a list to store names of libraries, and I would like to use foreach and find_library to find full path of each library. But find_library just returned the path of the first library. I checked this post, but problem still exist. My CMake version is 3.4.3.
SET(VTKLIBS_DIR)
FOREACH(LIB ${VTKLIBS})
SET(FOUND_LIB)
FIND_LIBRARY(FOUND_LIB ${LIB})
LIST(APPEND VTKLIBS_DIR ${FOUND_LIB})
MESSAGE("Lib: ${LIB}")
MESSAGE("Found Lib: ${FOUND_LIB}")
UNSET(FOUND_LIB)
ENDFOREACH(LIB)
Command find_library sets cached variable, but simple form of command unset remove only simple variable's definition.
As noted by the link you provide, you need to store special value FOUND_LIB-NOTFOUND to the variable FOUND_LIB for force find_library to search another library while variable already contains path to the previous library:
FOREACH(LIB ${VTKLIBS})
SET(FOUND_LIB "FOUND_LIB-NOTFOUND")
FIND_LIBRARY(FOUND_LIB ${LIB})
LIST(APPEND VTKLIBS_DIR ${FOUND_LIB})
MESSAGE("Lib: ${LIB}")
MESSAGE("Found Lib: ${FOUND_LIB}")
ENDFOREACH(LIB)
Actually, this is some kind of trick, as cached variable FOUND_LIB isn't changed by simple set command. But when find_library implementation attempts to read cached value of the variable, it actually read value of simple variable with the same name.
Because find_library treats only *-NOTFOUND cached values as "library not found", your trick with assigning empty value to the variable doesn't work.
The better approach, as noted by #arrowd, would be using different names for variable, used in different find_library() call:
FOREACH(LIB ${VTKLIBS})
FIND_LIBRARY(FOUND_LIB_${LIB} ${LIB})
LIST(APPEND VTKLIBS_DIR ${FOUND_LIB_${LIB}})
MESSAGE("Lib: ${LIB}")
MESSAGE("Found Lib: ${FOUND_LIB_${LIB}}")
ENDFOREACH(LIB)
Such a way results for every find_library call will be stored separately, and the same library will not be searched again at the next time cmake being invoked. Also, such approach allows user to modify (in cache) paths to concrete libraries without affecting other ones.