CMake link to only release config of target in both debug and release - cmake

Is there another a way to link only the release lib of a target when including the target with target_link_libraries for both release and debug configs.
I know target_link_libraries has the options optimize and debug and that it can be done like this
target_link_libraries(current_target
optimized $<TARGET_PROPERTY:lib_target,IMPORTED_IMPLIB_RELEASE>
debug $<TARGET_PROPERTY:lib_target,IMPORTED_IMPLIB_RELEASE>
)
However I generally keep the targets in a list
set(target_list
lib_target1
lib_target2
...
)
and I perform other things on the same list, like getting the binary directory of the target to include in the search path for debugging. Using the optimized and debug options also do not allow the lib_target... properties to be passed along through the current_target. I can work around it just curious if there is another way?

If you link with IMPORTED target, then its configuration-dependent properties refer to "imported configuration". You may always adjust mapping between configurations of your project and imported ones:
Global configuration mapping is adjusted by CMAKE_MAP_IMPORTED_CONFIG_<CONFIG> variables.
The setting below will use Release configuration of every IMPORTED target for any of Release, Debug or RelWithDebugInfo configurations of your project:
set(CMAKE_MAP_IMPORTED_CONFIG_RELEASE Release)
set(CMAKE_MAP_IMPORTED_CONFIG_DEBUG Release)
set(CMAKE_MAP_IMPORTED_CONFIG_RELWITHDEBUGINFO Release)
Note, that these settings should be issued before creating of IMPORTED targets. That is, if such targets are created with find_package() calls, the settings should precede these calls.
Per-target configuration mapping is adjusted by MAP_IMPORTED_CONFIG_<CONFIG> properties.
Settings below do the same as global settings above but only for lib_target1 IMPORTED target:
set_target_properties(lib_target1 PROPERTIES
MAP_IMPORTED_CONFIG_RELEASE Release
MAP_IMPORTED_CONFIG_DEBUG Release
MAP_IMPORTED_CONFIG_RELWITHDEBUGINFO Release)
These settings can be applied only after given IMPORTED target is created, e.g. after find_package() call.
It is worth to mention, that you may also specify fallback imported configurations:
set(CMAKE_MAP_IMPORTED_CONFIG_DEBUG Release Debug)
With such setting, if your project is built in Debug configuration, and some IMPORTED target doesn't have Release configuration, then its Debug configuration will be used. (But if that target has neither Release nor Debug configuration, CMake will emit an error).

Related

Using FetchContent with interdependent libraries yields "prefixed in the build directory" error

Consider the following: I have a project which depends on libwebsockets which is itself dependends on mbedtls. I pull everything in from github using FetchContent, which establishes the dependencies in the build folder (_deps).
As I want to build everything statically, I thought I might do libwebsockets a favor and setup CMAKE_PREFIX_PATH so that its find_path() calls will find mbedtls, so libwebsockets knows the path to mbedtls and can see its include files. At the same time I have set cache variables that libwebsockets uses in its find_library() calls variables to the targets in mbedtls, so they are always found even at configure time. More specifically, this is what libwebsocket does:
find_path(LWS_MBEDTLS_INCLUDE_DIRS mbedtls/ssl.h)
find_library(MBEDTLS_LIBRARY mbedtls)
find_library(MBEDX509_LIBRARY mbedx509)
find_library(MBEDCRYPTO_LIBRARY mbedcrypto)
So libwebsockets finds mbedtls in the build directory, everything good so far, but then I get this nasty error still at configure time:
CMake Error in build/_deps/libwebsockets-src/lib/CMakeLists.txt:
Target "websockets" INTERFACE_INCLUDE_DIRECTORIES property contains path:
"C:/dev/realtime-cpp/build/_deps/mbedtls-build/include"
which is prefixed in the build directory.
There are similar errors for the other targets. I understand that the include files are in the build directory. However I don't understand why this is a problem and what I should do instead?

Using target_link_libraries on specific configurations (MinSizeRel, Release, etc.) instead of general ones (Optimized or debug)?

From what I see from the target_link_libraries documentation, you can set the keyword debug, optimized or general before a library to define for what configuration to link it to. The problem is that I would like to have even more control and be able to specify a different library for Release, Debug, MinSizeRel and RelWithDebInfo. Is there a way to do this?
Command target_link_libraries accepts generator expressions, using which you may express almost any configuration-dependent logic.
Actually, specifying for target_link_libraries
debug libA
is effectively the same as using following generator expression:
$<$<CONFIG:Debug>:libA>
(More precise, it effectively the same with default setting of DEBUG_CONFIGURATIONS variable.)
If you want to link different flavors of the same library dependent on configuration, then the better way is using an IMPORTED library target combined with IMPORTED_LOCATION_<CONFIG> properties setting:
add_library(libA STATIC IMPORTED)
set_target_properties(libA PROPERTIES
IMPORTED_CONFIGURATIONS "Debug;Release"
IMPORTED_LOCATION_DEBUG "/foo/bar/libA_debug.a"
IMPORTED_LOCATION_RELEASE "/foo/bar/libA_release.a"
)
After that, plain
target_link_libraries(myExe PUBLIC libA)
will link with /foo/bar/libA_debug.a in 'Debug' configuration and with /foo/bar/libA_release.a in 'Release' configuration.

How to create debug and release versions of libraries

I'm releasing a library which will be able to install headers and .a libraries for reuse. I would like users to be able to link either to release or debug builds of the lib if they so desire. I know that I can use DEBUG_POSTFIX like in Create a directory based on Release/Debug build type in CMake. My question is how do the users differentiate between the two? They would still put target_link_libraries(mylib), so I don't understand how a debug build would be chosen.
If MyLibTargets.cmake is correctly made they don't specify between the two. MyLibTargets.cmake should properly set IMPORTED_CONFIGURATIONS and IMPORTED_LOCATION_<CONFIG> for the target mylib. Then Debug maps to the Debug location and Release maps to the Release location. This is done automatically using the export command for multi-configuration generator. It's not really any different how a multi-configuration generator chooses Debug / Release libraries for any regular library target.

Using protobuf with CMake's different build configurations (RelWithDebugInfo and Debug)

In my project I'm using protobuf 3.5. I need at least the debug and the RelWithDebugInfo configurations. To be able to build the project with protobuf debug libraries led to some problems alone:
I needed to build the protobuf libraries from source using both the release and the debug target since the _ITERATOR_DEBUG_LEVEL of my libraries (= 2) didn't match the level of the protobuf libraries (= 0). After building the debug libraries as well as the release libraries, compiling in debug configuration was possible.
Now, after changing back to RelWithDebugInfo I get the same error again, but now just the opposite: The _ITERATOR_DEBUG_LEVEL of my libraries is 0 and the level of the used protobuf libraries is 2.
When checking the linker configuration, I can see that my libraries are linked against the libprotobufd.lib. This makes sense since I've read somewhere that everything which is not Release will use the debug libraries, if available. And this leads to my problem:
I won't build my libraries in Release during development. It's most of the time RelWithDebugInfo. But the _ITERATOR_DEBUG_LEVEL for this configuration is obviously set to 0 (because it is a release configuration with additional information). But CMake then links against protobuf's debug libraries which are not compatible with the rest.
I'm now looking for a possibility to tell CMake to not use the debug version of the libraries but the release version instead without changing the CMake scripts of protobuf itself.
Normally my way to go would be to link different libraries depending on the actual build configuration. But unfortunately, the protobuf CMake configuration tries to handle this by itself.
# Load information for each installed configuration.
get_filename_component(_DIR "${CMAKE_CURRENT_LIST_FILE}" PATH)
file(GLOB CONFIG_FILES "${_DIR}/protobuf-targets-*.cmake")
foreach(f ${CONFIG_FILES})
include(${f})
endforeach()
whilst the imported target is overwritten selected depending on the actual configuration:
protobuf-targets-release.cmake:
# Import target "protobuf::libprotobuf-lite" for configuration "Release"
set_property(TARGET protobuf::libprotobuf-lite APPEND PROPERTY IMPORTED_CONFIGURATIONS RELEASE)
set_target_properties(protobuf::libprotobuf-lite PROPERTIES
IMPORTED_LINK_INTERFACE_LANGUAGES_RELEASE "CXX"
IMPORTED_LOCATION_RELEASE "${_IMPORT_PREFIX}/lib/libprotobuf-lite.lib"
)
protobuf-targets-debug.cmake:
# Import target "protobuf::libprotobuf-lite" for configuration "Debug"
set_property(TARGET protobuf::libprotobuf-lite APPEND PROPERTY IMPORTED_CONFIGURATIONS DEBUG)
set_target_properties(protobuf::libprotobuf-lite PROPERTIES
IMPORTED_LINK_INTERFACE_LANGUAGES_DEBUG "CXX"
IMPORTED_LOCATION_DEBUG "${_IMPORT_PREFIX}/lib/libprotobuf-lited.lib"
)
whereas the linking in my CMakeLists.txt looks like this:
target_link_libraries(${PROJECT_NAME} PRIVATE
protobuf::libprotobuf
protobuf::libprotoc
)
I don't see any possibility here to specify the desired library. Normally I'd say I would specify it somehow like this:
target_link_libraries(MyEXE
debug protobuf::libprotobufd optimized protobuf::libprotobuf
debug protobuf::libprotocd optimized protobuf::libprotoc)
or wrap some fancy if-condition for the different build configurations around it. But due to protobuf effectively overwriting the target, I don't know how to extract the correct library for each build.
Any ideas?
I'm now looking for a possibility to tell CMake to not use the debug version of the libraries but the release version instead
Variables CMAKE_MAP_IMPORTED_CONFIG_ are intended for resolve exactly that problem:
# When build your project in RelWithDebugInfo configuration,
# try to use Release configuration of the *IMPORTED* libraries.
# If some IMPORTED library has no Release configuration, fallback to Debug one.
set(CMAKE_MAP_IMPORTED_CONFIG_RELWITHDEBUGINFO Release Debug)
# Imported targets set with given call will be aware of the variable's set above
find_package(Protobuf REQUIRED)
# Simply link with an IMPORTED library.
target_link_libraries(MyExe protobuf::libprotobuf)
If you want to use Release configuration only from the specific IMPORTED libraries, but not all, you may set corresponded properties for these specific libraries:
# Firstly, create needed IMPORTED target.
find_package(Protobuf REQUIRED)
# Then adjust its properties.
# While the target is created by others, given property is specifically
# designed to be set in *your project*.
set_property(TARGET protobuf::libprotobuf PROPERTY MAP_IMPORTED_CONFIG_RELWITHDEBUGINFO Release Debug)
# Simply link with an IMPORTED library.
target_link_libraries(MyExe protobuf::libprotobuf)

CLion: issue with Cmake configuration types

I understand that by default, Clion creates the binary files for a project loaded in Clion in all the four configurations:
(Debug;Release;MinSizeRel;RelWithDebInfo)
as well as one called: __default__.
I am using a third party cmake module which downloads an external project in a way that add_subdirectory() can be run on it so it would be included in the root project.
add_subdirectory(${downloaded_proj_src_dir} ${downloaded_proj_bin_dir} EXCLUDE_FROM_ALL)
In this setup, if I decide to place the child project outside the binary directory of the root project, I get:
Error:Binary directories outside of CMake build directory are not supported. Most likely this error is caused by an add_subdirectory command with an explicitly specified binary_dir argument.
which is an understandable restriction by CMake.
now if I instead decide to set the binary directory of the downloaded project in a subdirectory of the binary directory of the parent project, ie:
set(downloaded_proj_bin_dir "${CMAKE_BINARY_DIR}/${downloaded_proj}-build")
...
add_subdirectory(${downloaded_proj_src_dir} ${downloaded_proj_bin_dir} EXCLUDE_FROM_ALL)
I will get the file created in the parent binary directory of all the build configurations because ${CMAKE_BINARY_DIR} is different for each configuration. To avoid seeing all these directories listed on the project view sidebar, I have set the CMAKE_CONFIGURATION_TYPES to be Debug. But even then, I get:
Error:Configuration Debug
The current CMakeCache.txt directory /path/Debug/downloaded_proj_bin/CMakeCache.txt is different than the directory /path/__default__/downloaded_proj_bin/CMakeCache.txt where CMakeCache.txt was created. This may result in binaries being created in the wrong place. If you are not sure, reedit the CMakeCache.txt
Clearly something is going on with this __default__ configuration which I don't understand. So the question is, what is the significance of this default configuration and why should there be a conflict here?
P.s. Setting the configuration to __default__ does not solve the problem as I will have a __default__0 configuration created instead and get the same error.
Update: some further observations
My enviornment variables set in IDE don't have any effect on the cmake builds.
Cmake "options" however which presumably will be passed as arguments to cmake do seem to work.
-D CMAKE_CONFIGURATION_TYPES=Debug.
When I specify the command line option, I get
Warning:Manually-specified variables were not used by the project:
CMAKE_CONFIGURATION_TYPES
But it clearly does have the effect of no longer creating the other build configurations. My guess is that this message relates to the __default__ build which is ignoring the argument.
Even in the case of specifying CMAKE_CONFIGURATION_TYPES in the IDE, I still get the additional __default__ build which is apparently unaffected by the CMAKE_CONFIGURATION_TYPES assignment.
Logging: message("Build type: ${CMAKE_BUILD_TYPE} ) does not return any build_type.
Outputting message(and generator: ${CMAKE_GENERATOR} ") returns "Unix-make files" for both, so both are being generated with the same generator.
Taking a diff from the CMakeCache.txt files, I can see that they are identical.
Do you have in DownloadProject.cmake the right setting? for:
set(_DownloadProjectDir "${CMAKE_CURRENT_LIST_DIR}")
I had the same problem trying to set google test(with the help of https://github.com/Crascit/DownloadProject) and my _DownloadProjectDir was setted as "test". Maybe when I moved this cmake file in my project Clion changed that automatically.
So, it turns out that you can sort this out quite easily by adding the following line above line 145 in DownloadProject.cmake:
file(REMOVE "${DL_ARGS_DOWNLOAD_DIR}/CMakeCache.txt")
This seems to be because CLion copies the default across to the other configurations and doesn't clear the cache. This is a problem only because DownloadProject creates a project within the project (I think...). Anyway, deleting this file before configuring the CMakeLists.txt by-passes this issue. I'll submit a pull request to the DownloadProject repository as this doesn't seem to have any adverse effects when not using CLion.