In my CMakeLists I have a statement:
target_link_libraries(mytarget somelib)
The problem is that I am working on Windows and somelib has a verbatim name - libsomelib.a. I cannot control that because the library is built by another person (who thinks it is a cool idea to name Windows libraries in a UNIX fashion) and installed somewhere.
Prior to the statement I have
set(CMAKE_STATIC_LIBRARY_PREFIX "lib")
set(CMAKE_STATIC_LIBRARY_SUFFIX ".a")
which seems to affect only libraries produced by a given CMakeLists,
and, in the list of dependencies (of a generated VS project) it still appears as somelib.lib.
My question is what can be done to get this dependent library properly named?
Related
I am writing a C++ library (header-only) and am using CMake to generate my (Visual Studio) project and solution files. I'm also writing a test suite, which is part of the same CMake project.
My problem occurs when I call target_include_directories() on the target that represents my header-only library, so that consumers of my library may find its header files. I get the following error message (even though generation is NOT aborted).
CMake Error in CMakeLists.txt:
Target "Fonts" INTERFACE_INCLUDE_DIRECTORIES property contains path:
"D:/Projects/GPC/fonts/include"
which is prefixed in the source directory.
(D:/Projects/GPC/Fonts being the top-level directory of my library project. Btw the problem remains if I move my header files to the top directory.)
The offending line in my CMakeLists.txt is this (adapted for simplicity):
target_include_directories(Fonts INTERFACE "${CMAKE_CURRENT_SOURCE_DIR}/include")
I do not understand what I'm doing wrong. Without target_include_directories(), code of consumer projects simply can't include my header files (unless in installed form, but I haven't gotten to that yet, and in any case I want to be able to use my library from its build tree, without installation.)
I feel like I'm missing something basic here; yet I've searched for hours without finding a solution or explanation.
The origin of the problem is not the target_include_directories command itself, but the attempt to install a target that has a public or interface include directory prefixed in the source path (i.e. the include directory is a subdirectory of your ${PROJECT_SOURCE_DIR}.)
While it is perfectly fine and desirable to use absolute paths when building the library from scratch, a third party library that pulls in a prebuilt version of that library will probably want to use a different include path. After all, you do not want all of your users to mirror the directory structure of your build machine, just to end up in the right include path.
CMake's packaging mechanism provides support for both of these use cases: You may pull in a library directly from the build tree (that is, check out the source, build it, and point find_package() to the directory), or from an install directory (run make INSTALL to copy built stuff to the install directory and point find_package() to that directory). The latter approach needs to be relocatable (that is, I build and install on my machine, send you the resulting directory and you will be able to use it on your machine from a different directory structure), while the former is not.
This is a very neat feature, but you have to account for it when setting up the include directories. Quoting the manual for target_include_directories:
Include directories usage requirements commonly differ between the
build-tree and the install-tree. The BUILD_INTERFACE and
INSTALL_INTERFACE generator expressions can be used to describe
separate usage requirements based on the usage location. Relative
paths are allowed within the INSTALL_INTERFACE expression and are
interpreted relative to the installation prefix. For example:
target_include_directories(mylib PUBLIC
$<BUILD_INTERFACE:${CMAKE_CURRENT_SOURCE_DIR}/include/mylib>
$<INSTALL_INTERFACE:include/mylib> # <prefix>/include/mylib
)
The BUILD_INTERFACE and INSTALL_INTERFACE generator expressions do all the magic:
$<INSTALL_INTERFACE:...>
Content of ... when the property is exported using install(EXPORT), and empty otherwise.
$<BUILD_INTERFACE:...>
Content of ... when the property is exported using export(), or when the target is used by another target in the same buildsystem.
Expands to the empty string otherwise.
I am trying to figure out how CMake is supposed to work for shared libraries. I create a shared library like so:
(in /mdp_opt/CMakeLists.txt:)
add_library (mdp_opt SHARED librarycomponent.cpp)
Now, a test executable uses this library:
(/test/CMakeLists.txt:)
add_executable (test test.cpp)
target_link_libraries(test PRIVATE mdp_opt)
If the library is marked STATIC (instead of SHARED as above), I can cmake -> built (under Visual Studio) and successfully run the executable. When it is marked SHARED (as in above), I need to do two things. First thing, is adding:
set(CMAKE_WINDOWS_EXPORT_ALL_SYMBOLS ON)
That is fine. However, now it still only works if I copy the file mdp_opt.dll from build/x64-debug/mdp_opt to build/x64-debug/test. But I don’t understand why this is needed?
In the book “professional CMake”, I read:
LINK_LIBRARIES
This target property holds a list of all libraries the target should
link to directly. It is initially empty when the target is created and
it supports generator expressions. An associated interface property
INTERFACE_LINK_LIBRARIES is supported. Each library listed can be one
of the following (emphasis mine):
• A path to a library, usually specified as an absolute path.
• Just the library name without a path, usually also without any
platform-specific file name prefix (e.g. lib) or suffix (e.g. .a, .so,
.dll).
• The name of a CMake library target. CMake will convert this to a
path to the built library when generating the linker command,
including supplying any prefix or suffix to the file name as
appropriate for the platform. Because CMake handles all the various
platform differences and paths on the project’s behalf, using a CMake
target name is generally the preferred method.
I was under the impression that
target_link_libraries(test PRIVATE mdp_opt)
expresses that I intend to link the output associated with the target mdp_opt with the test executable? Also, in my reading of the above book excerpt, my understanding is that the location of the .dll will convert to a path? If the purpose of this conversion is not to somehow tell the executable where to find the shared library, then what is that conversion for?
Basically, can anybody tell me how CMake is supposed to work for shared libraries, and why is works like that? Is a manual post-copy (possibly via CMake instructions) really needed, and the best for this scenario (of intermediate builds while developing)?
On windows you need to export symbols of a shared library or add a linker option that results in symbols being exported; otherwise the .lib file for linking the dll simply isn't generated. This is why you need
set(CMAKE_WINDOWS_EXPORT_ALL_SYMBOLS ON)
, use __declspec( dllexport ) or similar.
The other issue is the way windows locates dlls: It basically first searches the directory containing the executable and then continues the search via the PATH environment variable. This can result in issues locating the dll at runtime.
You can avoid this issue by setting the directory to place the runtime artefacts before generating the first one of the targets involved:
set(CMAKE_RUNTIME_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/bin)
...
add_library(mdp_opt ...)
...
add_executable(test ...)
Alternatively you could simply change the environment variable visible to the vs debugger:
set_target_properties(test PROPERTIES VS_DEBUGGER_ENVIRONMENT "PATH=$<TARGET_FILE_DIR:mdp_opt>;$ENV{PATH}")
If you're working with CTest, there's also a similar property for tests: ENVIRONMENT
If the purpose of [target_link_libraryes] is not to somehow tell the executable where to find the shared library, then what is that conversion for?
You still need to link a dll, or more precisely the corresponding import library; this is what target_link_libraries does, in addition to adding build system dependencies, transferring some properties (e.g. include directories with PUBLIC visibility), ect.
I'm updating a (very old) find-module of a library. So the situation is an existing shared library which uses CMake itself. Users might already have this installed somewhere, in package repos or whatever.
Now they want to use this. The good way would be
find_package(Foo REQUIRED)
target_link_libraries(MyProject Foo::Foo)
So thats the goal.
The question is: How would a good find_package-Config or -Module look like which allows this 2-liner to work? It should meet these 2 requirements:
Allow a CMake version to use the library older than the one used to build it
Enforce e.g C++11 mode. In a Find-Module one can set the C++11 requirement based on the version (cxx_std_11 (CMake 3.8+), cxx_alias_templates (CMake 3.1+), check_cxx_source_compiles with C++11 code and a warning for older CMakes)
There are 2 ways of doing that:
Update the find-module to define an imported library Foo::Foo and set it up correctly (using properties) and be nice to also set FOO_INCLUDE_DIR and FOO_LIBRARIES for old CMake w/o targets.
This is pretty easy: Just use find_path and find_library, set up the imported target and be done. Works forwards and backwards compatible so even the old versions would be found.
Usage:
The user copies (the most recent) FindFoo.cmake to its project into e.g. cmake/Modules and points CMAKE_MODULE_PATH to it, or copy FindFoo.cmake to some CMake default path.
Listening to Daniel Pfeiffer and Modern CMake which says If you are the library author, don't make a Find<mypackage>.cmake script! So we export and install targets.
This is a bit messy. Following changes are required:
Add EXPORTS FooTargets and INCLUDES DESTINATION include to install(TARGETS (see Pfeiffer #24) which basically just defines an export. (I don't really see, why I would want to create an extra name for something that already has a name. Why can't the below command not simply refer to a target?)
Add install(EXPORT FooTargets NAMESPACE Foo:: DESTINATION lib/cmake/Foo) which would create a FooTargets.cmake in <CMAKE_INSTALL_PREFIX>/lib/cmake/Foo that defines a target Foo::Foo with (hopefully) all its dependencies
Add "something" creating FooConfigVersion.cmake possibly by using write_basic_package_version_file that, to my understanding, hard-codes the version to that file
Create a FooConfig.cmake that may use find_dependency to search for libraries that Foo depends on and includes FooTargets.cmake
Install FooConfig.cmake and FooConfigVersion.cmake to lib/cmake/Foo
modify target_include_directories to use separate BUILD_INTERFACE and INSTALL_INTERFACE paths
Usage:
find_package automatically finds the FooConfig.cmake and FooConfigVersion.cmake when Foo is searched for.
So the Config-Module should be preferred but problems I see are:
The process looks more complicated
It cannot be used to enable users to find older versions of the library (that did not use this approach)
It excludes all (library-)users with older CMake (2.8.11 is probably the minimum required here)
It requires a newer CMake version to build the library itself
The C++11 requirement seems to be very hard to encode
So can we solve the requirements with a CMake-Config? An answer should provide a solution or at least a well grounded "impossible". It should also address the problems outlined at the end.
Final Note: I guess this makes a nice wiki-entry if it doesn't exist.
This question asks how to install a shared library with cmake which has been imported rather than being built by the current project:
Can I install shared imported library?
To repeat the issue:
add_library(libfoobar SHARED IMPORTED)
# this install command is illegal
install(TARGET libfoobar LIBRARY DESTINATION "${RPMBUILDROOT}${LIBDIR}")
This was raised as a [https://gitlab.kitware.com/cmake/cmake/issues/14311|issue] with cmake that has been closed, effectively with a resolution of will not fix. The grounds are, quite reasonably, that cmake does not know enough about an imported target to reliably install it.
One point the answer to that question misses is that install(TARGET) will automagically create links from libfoo.so to libfoo.so.major and libfoo.so.minor version on GNU/Linux and other unix-like platforms where this is required.
Is there a way to hijack cmake into treating a custom target as if it was built by the project or otherwise persuade it to create those links?
Something like:
add_library(libfoobar SHARED IMPORTED)
#? add_custom_target(X libfoobar)
install(TARGET X LIBRARY DESTINATION "${RPMBUILDROOT}${LIBDIR}")
What is a canonical way to do this?
When a library is built by CMake, it is CMake who assigns soversion numbers to it (according to project's settings).
When a library isn't built by CMake, CMake doesn't know soversion, so it cannot create symlinks for you.
If you bother about that CMake actually installs symlink instead of file, resolve symlinks before installing, like in that question.
Well, you may ask CMake to guess soversion of the library (e.g. by resolving symlinks and checking their names). But why you ever need symlinks?
The main purpose of soversion symlink is to resolve compatibility issues with the future library's updates. But updates are possible only when the library is installed by the project who creates it.
If your project installs library produced by other project, it is unlikely that you want to support updates for the local library's installation. So there is no needs for you to support soversions.
I have built a server binary using cmake (and also make) for arm and x86 targets. I am able to run my server on arm using correct linking paths for RPATH, for example populating CMAKE_INSTALL_RPATH. However when I try to run my x86 server it complains about not being able to find my databases. Would I be right in saying that CMAKE_INSTALL_RPATH is used for libraries only and not to find files or databases. Is there another cmake variable that is used to find files or databases at run time or by correctly populating CMAKE_INSTALL_RPATH it should find files and databases as-well as libraries.
Thanks Paul.
You are correct that the CMAKE_INSTALL_RPATH only deals with finding shared libraries. Specifically, setting the RPATH just gives the dynamic linker a list of directories to search for shared libraries.
If you want to find a file or database at runtime from within your application, you have to get the paths into your application some other way. This could be via a config file or hardcoded constants that are different for each platform.