In the cmake docs for variables, There are four suffix variables:
CMAKE_SHARED_LIBRARY_SUFFIX # == .dll in Windows
CMAKE_STATIC_LIBRARY_SUFFIX # == .lib in Windows
CMAKE_IMPORT_LIBRARY_SUFFIX #
CMAKE_LINK_LIBRARY_SUFFIX # == .lib in Windows
I understand the static, shared and even import (It's just by design that import libraries in windows are also .lib).
But I don't understand why the CMAKE_LINK_LIBRARY_SUFFIX exists; It seems like it's all of the others combined or something like it. The docs simply explains what's already in the variable name. can someone explain exactly what this variables are used for.
Edit:
Even though the docs for CMAKE_IMPORT_LIBRARY_SUFFIX don't say that by default on windows it is equal to .lib. when I test it's value on my windows machine, .lib is the default.
Related
I'm new with CMake. I have to adapt a CMakeLists.txt file in the following way:
The projects has several subdirs, one which we'll call "subdir" from now.
The rest of the ( C++ based ) code can include files from this directory using the "#include" syntax. Now what I basically want to do is provide multiple versions of subdir (subdir1, subdir2 etc.) and switch between them using a CMake variable. However, for the code this switch should be transparent, it only sees a directory "subdir". It should be made sure that gcc notices the switch though and rebuilds everything if the variable is changed.
What would be the best way to achieve this in your opinion? Should work at least on Windows and Linux.
Regards
To develop what #alex-reinking proposed in the comment.
In the CMakeLists.txt you can selectively choose the directory to include at configure time with something like:
# expose cmake option to control the subdir
option(USE_IMPL "The implementation subdir" defaultSubdir)
# include it
add_subdirectory("${USE_IMPL}")
target_include_directories("${CMAKE_CURRENT_SOURCE_DIR}/${USE_IMPL}")
target_link_libraries(TheTarget library_target_in_subdir)
Build OS: Windows 10, Cmake 3.16.3.
I use target_link_libraries to link 3rd party .lib file to my .dll library.
But when I use GET_RUNTIME_DEPENDENCIES to install my dll, there is no dependency found.
It happens only on Windows, installing on Linux is ok.
Is there any clues how to solve this problem, or at least how to debug it?
What exact command uses CMake on Windows to determine dependencies?
I call GET_RUNTIME_DEPENDENCIES like this:
file(GET_RUNTIME_DEPENDENCIES
RESOLVED_DEPENDENCIES_VAR RES
UNRESOLVED_DEPENDENCIES_VAR UNRES
CONFLICTING_DEPENDENCIES_PREFIX CONFLICTING_DEPENDENCIES
EXECUTABLES ${EXECS}
LIBRARIES ${LIBS} ${MODULES} ${QTPLUGINS_LIBS}
DIRECTORIES ${RUNTIME_DEPENDENCIES_DIRECTORIES}
POST_EXCLUDE_REGEXES ${PLATFORM_POST_EXCLUDE_REGEXES}
)
Where LIBS contains my dll but no RES no UNRES contains path to 3rd paty dll.
So, there's a serious nastiness to all this runtime-dependency-finding magic in the newer CMakes, and it's not really their fault at all. The problem is that you, I, and roughly 90% of the rest of the CMake user world have been doing find modules wrong #THISWHOLETIME, and now our chickens have come home to roost because, as you've likely discovered, GET_RUNTIME_DEPENDENCIES / RUNTIME_DEPENDENCY_SET, $<TARGET_RUNTIME_DLLS> will all completely sh*t the bed if you try to use them with targets that have (what I now know to be) broken IMPORTED dependencies created by Find modules that don't properly set them up. So, last month I posted this screed (my earlier link) over at the CMake Discourse forum:
Windows libraries, Find modules, and TARGET_RUNTIME_DLLS
The Windows DLL Question™ has come up numerous times before in one form or another, but it’s cast in a new light by $<TARGET_RUNTIME_DLLS>, so here’s a fresh take on it.
If you’re like me (and roughly 90% of all CMake users/developers out there are like me, from what I’ve been able to observe in public projects’ source trees), your approach to writing Find modules on Windows has probably been something like this:
Use the same code on all three desktop platforms
Let CMake discover .lib / .dll.a import libraries instead of actual DLLs, using find_library().
End up creating your targets as UNKNOWN IMPORTED, because if you try to create SHARED IMPORTED library targets with only an import library it won’t work, but UNKNOWN IMPORTED works just fine so meh.
Set the import library as the target’s IMPORTED_LOCATION since that seems to work fine.
Call it a day, because hey — everything compiles.
That’s served us all for years (decades, really) so we’ve mostly just accepted it as the way CMake works on Windows.
But now along comes $<TARGET_RUNTIME_DLLS>. If you’ve tried to actually use it on Windows, you’ve probably discovered is that while all of your CONFIG-mode package dependencies’ DLLs are captured just fine, the generator expression will cheerfully ignore any targets created from a Find module that’s written like I describe above. …Which is probably most of them. (In my own library build, it was all of them, even the ones I didn’t write.)
For $<TARGET_RUNTIME_DLLS> to work, the IMPORTED target has to be correctly defined as a SHARED library target, and it needs to have its IMPORTED_ properties set correctly: import lib path in IMPORTED_IMPLIB, DLL path in IMPORTED_LOCATION.
So, now I have this new module that uses DLLTOOL.EXE and its handy -I flag to get the name of an import library’s DLL, then looks it up using find_program(). (Simply because find_library() won’t match DLLs, and I wanted to look on the PATH. I could’ve used find_file() but I’m pretty sure I’d have to explicitly give it more paths to search.)
The macro takes one argument, the name of your already-configured variable <prefix>_IMPLIB. (Or <prefix>_IMPLIBS, it’s pluralization agnostic and will follow whichever form your input uses when naming its output variable.)
The variable whose name you pass to it should already contain a valid path for an import library. Typically that’s set by find_library(), even though we’ve all been treating them like runtime libraries (DLLs) when they are not.
Armed with find_library(<prefix>_IMPLIB ...) output, implib_to_dll(<prefix>_IMPLIB) will attempt to discover and automatically populate the corresponding variable <prefix>_LIBRARY with the path to the import lib’s associated runtime DLL.
With all of the correct variables set to the correct values, it’s now possible to properly configure SHARED IMPORTED library targets on Windows. $<TARGET_RUNTIME_DLLS> can then be used to discover and operate on the set of DLLs defined by those target(s).
Kind of a pain in the Find, and really does sort of feel like something CMake could be doing at-least-semi-automatically. But, at least for now it works.
Now I just have to rewrite all of my find modules to use it. Sigh.
ImplibUtils.cmake
#[=======================================================================[.rst:
IMPLIB_UTILS
------------
Tools for CMake on WIN32 to associate IMPORTED_IMPLIB paths (as discovered
by the :command:`find_library` command) with their IMPORTED_LOCATION DLLs.
Writing Find modules that create ``SHARED IMPORTED`` targets with the
correct ``IMPORTED_IMPLIB`` and ``IMPORTED_LOCATION`` properties is a
requirement for ``$<TARGET_RUNTIME_DLLS>`` to work correctly. (Probably
``IMPORTED_RUNTIME_DEPENDENCIES`` as well.)
Macros Provided
^^^^^^^^^^^^^^^
Currently the only tool here is ``implib_to_dll``. It takes a single
argument, the __name__ (_not_ value!) of a prefixed ``<prefix>_IMPLIB``
variable (containing the path to a ``.lib`` or ``.dll.a`` import library).
``implib_to_dll`` will attempt to locate the corresponding ``.dll`` file
for that import library, and set the variable ``<prefix>_LIBRARY``
to its location.
``implib_to_dll`` relies on the ``dlltool.exe`` utility. The path can
be set by defining ``DLLTOOL_EXECUTABLE`` in the cache prior to
including this module, if it is not set implib_utils will attempt to locate
``dlltool.exe`` using ``find_program()``.
Revision history
^^^^^^^^^^^^^^^^
2021-11-18 - Updated docs to remove CACHE mentions, fixed formatting
2021-10-14 - Initial version
Author: FeRD (Frank Dana) <ferdnyc#gmail.com>
License: CC0-1.0 (Creative Commons Universal Public Domain Dedication)
#]=======================================================================]
include_guard(DIRECTORY)
if (NOT WIN32)
# Nothing to do here!
return()
endif()
if (NOT DEFINED DLLTOOL_EXECUTABLE)
find_program(DLLTOOL_EXECUTABLE
NAMES dlltool dlltool.exe
DOC "The path to the DLLTOOL utility"
)
if (DLLTOOL_EXECUTABLE STREQUAL "DLLTOOL_EXECUTABLE-NOTFOUND")
message(WARNING "DLLTOOL not available, cannot continue")
return()
endif()
message(DEBUG "Found dlltool at ${DLLTOOL_EXECUTABLE}")
endif()
#
### Macro: implib_to_dll
#
# (Win32 only)
# Uses dlltool.exe to find the name of the dll associated with the
# supplied import library.
macro(implib_to_dll _implib_var)
set(_implib ${${_implib_var}})
set(_library_var "${_implib_var}")
# Automatically update the name, assuming it's in the correct format
string(REGEX REPLACE
[[_IMPLIBS$]] [[_LIBRARIES]]
_library_var "${_library_var}")
string(REGEX REPLACE
[[_IMPLIB$]] [[_LIBRARY]]
_library_var "${_library_var}")
# We can't use the input variable name without blowing away the
# previously-discovered contents, so that's a non-starter
if ("${_implib_var}" STREQUAL "${_library_var}")
message(ERROR "Name collision! You probably didn't pass "
"implib_to_dll() a correctly-formatted variable name. "
"Only <prefix>_IMPLIB or <prefix>_IMPLIBS is supported.")
return()
endif()
if(EXISTS "${_implib}")
message(DEBUG "Looking up dll name for import library ${_implib}")
execute_process(COMMAND
"${DLLTOOL_EXECUTABLE}" -I "${_implib}"
OUTPUT_VARIABLE _dll_name
OUTPUT_STRIP_TRAILING_WHITESPACE
)
message(DEBUG "DLLTOOL returned ${_dll_name}, finding...")
# Check the directory where the import lib is found
get_filename_component(_implib_dir ".." REALPATH
BASE_DIR "${_implib}")
message(DEBUG "Checking import lib directory ${_implib_dir}")
# Add a check in ../../bin/, relative to the import library
get_filename_component(_bindir "../../bin" REALPATH
BASE_DIR "${_implib}")
message(DEBUG "Also checking ${_bindir}")
find_program(${_library_var}
NAMES ${_dll_name}
HINTS
${_bindir}
${_implib_dir}
PATHS
ENV PATH
)
set(${_library_var} "${${_library_var}}" PARENT_SCOPE)
message(DEBUG "Set ${_library_var} to ${${_library_var}}")
endif()
endmacro()
GET_RUNTIME_DEPENDENCIES isn't aware of your configure-time variables, so will you need to specify them manually. This answer states you can pass-on the variables to the install step, but I haven't been able to make it work so far. Fortunately, it does support generator expressions.
Another problem in your snippet is it must be called at install time. For example in an install(CODE ...) block.
So with all this in mind, this should get you started.
install(CODE [[
file(GET_RUNTIME_DEPENDENCIES
RESOLVED_DEPENDENCIES_VAR RES
UNRESOLVED_DEPENDENCIES_VAR UNRES
CONFLICTING_DEPENDENCIES_PREFIX CONFLICTING_DEPENDENCIES
EXECUTABLES $<TARGET_FILE:your_executable_target_name>
LIBRARIES $<TARGET_FILE:a_lib_target_name>
)
message("\n\nFound dependencies :")
foreach(DEP ${RES})
message("${DEP}")
endforeach()
message("\n\nNot found dependencies :")
foreach(DEP ${UNRES})
message("${DEP}")
endforeach()
]])
Build your install target to see the results.
cmake ..
cmake --build . --target install
In my application suite I build Libtiff from source and then link it to an application that I write myself. Libtiff's CMakeLists.txt files specify that the static libraries go into the library location CMAKE_INSTALL_FULL_LIBDIR, determined by CMake's GNUInstallDirs option.
When I first built and tested my application, I did so in Debian and on this platform CMAKE_INSTALL_FULL_LIBDIR gets set to ${CMAKE_INSTALL_PREFIX}/lib. Well and good, so in my own application's CMakeLists.txt file I told it to search for the the static tiff libraries there. No problem...
Now I've taken the same build suite to a Red Hat Linux platform (Pengwin Enterprise for WSL), and it turns out that here CMAKE_INSTALL_FULL_LIBDIR gets set to ${CMAKE_INSTALL_PREFIX}/lib64. I've checked the CMake documentation and it seems to say that in fact the choice of 'lib' or 'lib64' is determined automatically and is platform-dependent.
So, in my own application's CMakeLists.txt file, is there a way of finding out which it is on my current platform? How else am I supposed to guess where to look for the library? I've looked round but I can't find a CMAKE standard variable that holds the platform-dependent string, so the only things I can think of are:
Try 'lib', and if that doesn't work try 'lib64', or
Create a new CMAKE_INSTALL_FULL_LIBDIR in my own CMakeLists.txt file and read the end of it
...but both these seem clunkily inelegant and there surely must be a better way.
GNUInstallDirs module documents the CMAKE_INSTALL_LIBDIR variable which sounds like it contains the value you want.
CMAKE_INSTALL_LIBDIR = lib
CMAKE_INSTALL_FULL_LIBDIR = /lib
Also find_library should also be searching lib and lib64 as necessary in the default path search even when using CMAKE_LIBRARY_PATH to define a custom prefix.
We have a CMakeLists.txt that links (for instance) opencv to our various binaries. This is done as follow:
find_package(OpenCV REQUIRED core imgproc highgui contrib)
target_link_library(XXX opencv_core)
We also would like to allow the person building the library to provide its own opencv library. It seems that this could be done setting -DCMAKE_PREFIX_PATH to the right path.
cmake -DCMAKE_PREFIX_PATH=".../mybuild/include;.../mybuild/lib" .
However I would like to be sure the library used is exactly the one specified by the client (i.e. if there is nothing in /mybuild/lib the configuration fails).
How can I allow somebody building the library to override the library used ? (if nothing is specified it should fall back to find_package-s)
In short
If the package provides <package>Config.cmake script, user may specify <package>_DIR CMake variable for locate this script.
Searching other places in that case may be disabled with NO_DEFAULT_PATH option for find_package().
If a package is searched with Find<package>.cmake script, there is no (generic) way for disable searching other places if user provides hint variable but it is wrong.
Explanations
Firstly, CMAKE_PREFIX_PATH provides additional installation tree for all packages. As this variable is applied to all find_package() calls, it is not wise to require all packages to be found under it.
When talk about the ways for specify installation directory for specific package, we need to distinguish two kinds of "find" scripts:
<package>Config.cmake (or some alternative names, see find_package documentation).
These scripts are shipped with the packages themselves. And there is universal way for user to specify location of such packages: CMake variable <package>_DIR, which should point to the directory with *Config.cmake script.
While default behaviour of find_package() is treating <package>_DIR variable as an additional hint, passing NO_DEFAULT_PATH option disables all implicit paths:
if(<package>_DIR) # Variable is set by the user or by previous `cmake` run.
# Search only under given directory.
find_package(<package> NO_DEFAULT_PATH)
else()
# Search everywhere (as documented for 'find_package').
find_package(<package>)
endif()
Find<package>.cmake.
This script either is shipped with CMake or should be shipped with the project.
Most of such scripts allows to hint about package location with variable (CMake or environment one) like <package>_DIR, <package>_ROOT or so.
However, almost all such scripts treat hint variable only as additional search place, so if variable is set to wrong value, they simply ignore it. And without modifying the script you cannot change that behavior.
I currently want to create an installer with cmake, but don't add all necessary DLLs by myself to CMakeLists.txt. So one solution should be to use fixup_bundle, like here suggested, so hopefully he copy all DLLs, which he can detect with a dependency walker and are on path.
But currently I have no idea how is best way to use it on a target, following code won't work, because he don't resolve TARGET_FILE_DIR like if you are using add_custom_command. Do read location via get_property won't work too, because he don't know the target anymore at time of execution. Any idea?
INSTALL(CODE "
include(BundleUtilities)
fixup_bundle($<TARGET_FILE_DIR:${PROJECT_NAME}> \"\" \"D:\\Qt\")
" COMPONENT Runtime
)
If you are using Qt4, rather than using BundleUtilities directly, you may be better off using the DeployQt4 module. It includes the following three commands which may do what you need:
install_qt4_plugin_path
install_qt4_plugin
install_qt4_executable
If you are using Qt5, it gets a bit trickier. If you are only interested in Windows and/or Mac, then Qt itself provides an appropriate tool for handling/bringing across Qt's dependencies. The relevant tools are called windeployqt and macdeployqt respectively. Sadly, at time of writing, there is no linuxdeployqt tool yet that I'm aware of.
If neither of the above options are open to you or don't do what you need, then at least the DeployQt4 module gives some clues as to how you may be able to use the INSTALL(...) command like you attempted to. The DeployQt4 module uses the following for defining its target (see right near the end of the DeployQt4.cmake file):
FIXUP_QT4_EXECUTABLE(\"\$ENV{DESTDIR}\${CMAKE_INSTALL_PREFIX}/${executable}\" \"\" \"${libs}\" \"${dirs}\" \"${plugins_dir}\" \"${request_qt_conf}\")"
${component}
)
The stuff in front of ${executable} is probably the bit you were missing. In your case, without seeing your full CMakeLists.txt file, I can only assume that you have a single target and it has the same name as your project (since you used ${PROJECT_NAME} in your attempted generator expression). You could try something like the following (not tested):
INSTALL(CODE "
include(BundleUtilities)
fixup_bundle(\"\$ENV{DESTDIR}\${CMAKE_INSTALL_PREFIX}/${MyTarget}\" \"\" \"D:\\Qt\")
" COMPONENT Runtime
)
where MyTarget is the name of the executable for your target (I think without any .exe suffix if you are on Windows). The DESTDIR part is needed when making packages, since CMake will redirect the install location by setting the DESTDIR environment variable (at least with some CMake generators). The CMAKE_INSTALL_PREFIX part is the path under which the application would be installed. There is some history behind this, but the above reflects the correct way of how to refer to the installed executable.