If I have a line install( TARGETS prog DESTINATION foo ) in my CMakeLists.txt, the target gets installed in CMAKE_INSTALL_PREFIX/foo/prog, so I figured having
install( TARGETS prog ) would put it in CMAKE_INSTALL_PREFIX/prog. But no, it goes in CMAKE_INSTALL_PREFIX/bin/prog.
How can I install a target directly in the prefix location?
You can use . as the destination:
install(TARGETS prog DESTINATION .)
If you don't specify the destination, the default path for executables is used, which is bin.
Related
I am trying to import vector_blf into a project with FetchContent_Declare() like this:
FetchContent_Declare(
vector_blf
GIT_REPOSITORY https://github.com/Technica-Engineering/vector_blf.git
GIT_TAG 02f0a2fe1f7915da1e24025869b98f6d15de937b
)
FetchContent_MakeAvailable(vector_blf)
target_link_libraries(labplot2lib Vector_BLF)
.
.
.
add_executable( labplot2 ${LABPLOT_SOURCE} ${qml_QRC} )
target_link_libraries( labplot2 labplot2lib )
install( TARGETS labplot2 ${KDE_INSTALL_TARGETS_DEFAULT_ARGS})
with KDE_INSTALL_TARGETS_DEFAULT_ARGS
RUNTIMEDESTINATIONbinLIBRARYDESTINATIONlibARCHIVEDESTINATIONlibCOMPONENTDevelINCLUDESDESTINATIONinclude
this works fine and it builds on windows and linux. The library of vector_blf target is installed to lib which is fine on linux, but on windows it needs to be in bin. But it will not be considered even with RUNTIME DESTINATION to bin.
in the vector_blf project they are using GnuInstallDirs and
install(
TARGETS ${PROJECT_NAME}
DESTINATION ${CMAKE_INSTALL_LIBDIR})
to install the library.
I tried to overwrite the RUNTIME_OUTPUT_DIRECTORY of Vector_BLF with set_target_properties but with no success.
What is the proper way to install the library to the bin folder?
For the following CMakeLists.txt file
cmake_minimum_required(VERSION 3.15)
project(Testing)
include(CMakePackageConfigHelpers)
configure_package_config_file(FooConfig.cmake.in
${CMAKE_CURRENT_BINARY_DIR}/FooConfig.cmake
INSTALL_DESTINATION lib/Goo/dmake
)
install(FILES ${CMAKE_CURRENT_BINARY_DIR}/FooConfig.cmake
DESTINATION lib/Foo/cmake )
and the FooConfig.cmake.in file
#PACKAGE_INIT#
check_required_components(Foo)
It would finally install FooConfig.cmake to lib/Foo/cmake：
$ cmake ..
$ cmake --build .
$ cmake --install . --prefix ../install/
$ ls -R ../install/
../install/:
lib
../install/lib:
Foo
../install/lib/Foo:
cmake
../install/lib/Foo/cmake:
FooConfig.cmake
It seems that whatever value I set to the INSTALL_DESTINATION option of configure_package_config_file, it won't change FooConfig.cmake's installation directory. But if I comment INSTALL_DESTINATION lib/Goo/dmake, CMake Error prompts
No INSTALL_DESTINATION given to CONFIGURE_PACKAGE_CONFIG_FILE()
Then, what is the use of the INSTALL_DESINATION option? What its value (specifically, the above setting lib/Goo/dmake) actually affects?
The documentation:
The <path> given to INSTALL_DESTINATION must be the destination where the FooConfig.cmake file will be installed to.
I know the right way is INSTALL_DESTINATION lib/Foo/cmake. But as I deliberately set it as lib/Goo/dmake, the FooConfig.cmake file still rests at the desired destination lib/Foo/cmake. So, why this option is designed as a must?
The function configure_package_config_file only generates the file specified as the second argument. This function neither installs the generated file nor affects on its installation. So, its arguments can only affect on the content of the generated file.
If you look into the generated script FooConfig.cmake, then you could find the line like
get_filename_component(PACKAGE_PREFIX_DIR "${CMAKE_CURRENT_LIST_DIR}/../../../" ABSOLUTE)
This is how the script calculates installation prefix based on the path to the FooConfig.cmake file.
E.g. when you install the package with prefix /usr/local and your FooConfig.cmake script will be located in the directory /usr/local/lib/Foo/cmake, then the quoted path will be expanded into /usr/local/lib/Foo/cmake/../../../, which corresponds to /usr/local/.
Number of components ../ in the script equals to the number of components in INSTALL_DESTINATION parameter.
Why 'PACKAGE_PREFIX_DIR' is needed
Assume a package installs all public headers into directory include/ (relative to installation prefix), and config script needs to deliver that directory to the user via variable FOO_INCLUDE_DIR.
The most direct way would be to write in the script following:
# FooConfig.cmake.in
...
set(FOO_INCLUDE_DIR #CMAKE_INSTALL_PREFIX#/include)
so configure_package_config_file would substitute real install prefix instead of #CMAKE_INSTALL_PREFIX#.
But embedding absolute path into the config file prevents the package to be relocatable. So, once installed, the package could be used only from the installation directory, and cannot be copied elsewhere.
For relocatable package a config file computes all installation paths relative to the path of the config file itself, because it is the only path known to the script when it is called by find_package. It is like an executable can compute paths to the files located near to that executable.
If the script is installed into lib/Foo/cmake/FooConfig.cmake, then relative path to the include directory would be ../../../include, so one could use following assignment in that script:
# FooConfig.cmake.in
...
set(FOO_INCLUDE_DIR ${CMAKE_CURRENT_LIST_DIR}/../../../include)
So, when find_package(Foo) will execute this script, it expands the variable CMAKE_CURRENT_LIST_DIR to the actual directory with the possibly relocated script.
Operating with relative paths requires much attention from the coder, so CMake allows to automate this task:
# CMakeLists.txt
...
# Path to the include directory in the installation tree
set(INCLUDE_DIR 'include')
configure_package_config_file(FooConfig.cmake.in
${CMAKE_CURRENT_BINARY_DIR}/FooConfig.cmake
INSTALL_DESTINATION lib/Foo/cmake
# Tell CMake to handle variable `INCLUDE_DIR` as a path
# under installation tree.
PATH_VARS INCLUDE_DIR
)
# FooConfig.cmake.in
#PACKAGE_INIT#
# Here we could use `#PACKAGE_INCLUDE_DIR#` as reference
# to variable 'INCLUDE_DIR' set in the CMakeLists.txt.
set_and_check(FOO_INCLUDE_DIR "#PACKAGE_INCLUDE_DIR#")
If you look into the generated file, you will find that #PACKAGE_INCLUDE_DIR#
is expanded into ${PACKAGE_PREFIX_DIR}/include, which uses the variable PACKAGE_PREFIX_DIR.
I'm having problems convincing cmake/cpack to generate a debian package that contains a single executable quine stored in a specific folder named /absolute/path.
According to https://cmake.org/cmake/help/v2.8.0/cmake.html#command:install I should be able to use an absolute path:
DESTINATION arguments specify the directory on disk to which a file
will be installed. If a full path (with a leading slash or drive
letter) is given it is used directly. If a relative path is given it
is interpreted relative to the value of CMAKE_INSTALL_PREFIX.
Here is my C file quine.c:
char*s="char*s=%c%s%c;main(){printf(s,34,s,34);}";main(){printf(s,34,s,34);}
and my CMakeLists.txt file:
cmake_minimum_required(VERSION 2.8)
project(quine)
file(GLOB SOURCES ${CMAKE_CURRENT_SOURCE_DIR}/*.c)
add_executable(quine ${SOURCES})
set(CPACK_GENERATOR "DEB")
set(CPACK_DEBIAN_PACKAGE_MAINTAINER "Nobody")
install(
TARGETS quine
RUNTIME DESTINATION /absolute/path
)
include(CPack)
In an empty subdirectory called build I invoke the following:
$ cmake ..
$ make package
and the resulting package is only 512 bytes in length, and a:
$ dpkg -c quine-0.1.1-Linux.deb
confirms that the package is empty.
What am I doing wrong?
First off, I'm relatively new to cmake. I'm trying to use cmake to build a project with a single external dependency. I specify the INSTALL_DIR for the external project to be CMAKE_INSTALL_PREFIX, so it installs to the same place as the parent project. But when I run make, it ignores it and tries to install to /usr/local/lib.
Here's my CMakeList.txt:
cmake_minimum_required( VERSION 2.8 )
include( ExternalProject )
project( capture )
add_library( capture SHARED capture.cc )
set( CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -std=c++11" )
ExternalProject_Add( proj_exceptions
GIT_REPOSITORY /home/user/workspace/exceptions
INSTALL_DIR ${CMAKE_INSTALL_PREFIX}
)
add_library( exceptions SHARED IMPORTED )
set_property( TARGET exceptions
PROPERTY IMPORTED_LOCATION ${CMAKE_INSTALL_PREFIX}/lib/libexceptions.so
)
add_dependencies( exceptions proj_exceptions )
include_directories( ${CMAKE_INSTALL_PREFIX}/include )
target_link_libraries( capture exceptions )
install( TARGETS capture DESTINATION lib )
install( FILES capture.h DESTINATION include )
CMakeLists.txt for the external project looks like this:
cmake_minimum_required( VERSION 2.8 )
project( exceptions )
add_library( exceptions SHARED exceptions.cc )
install( TARGETS exceptions DESTINATION lib )
install( FILES exceptions.hh DESTINATION include )
It clones and builds the external project just fine, but it chokes on the install step:
Install the project...
-- Install configuration: ""
-- Installing: /usr/local/lib/libexceptions.so
CMake Error at cmake_install.cmake:42 (file):
file INSTALL cannot copy file
"/home/user/workspace/capture/build/proj_exceptions-prefix/src/proj_exceptions-build/libexceptions.so"
to "/usr/local/lib/libexceptions.so".
Makefile:66: recipe for target 'install' failed
As you can see, the install configuration is empty. Looking through the generated config for the external project, I found this in cmake_install.cmake:
if(NOT DEFINED CMAKE_INSTALL_PREFIX)
set(CMAKE_INSTALL_PREFIX "/usr/local")
endif()
So, it seems that passing INSTALL_DIR to ExternalProject_Add doesn't set the install prefix. The install step succeeds, if I instead use:
ExternalProject_Add( proj_exceptions
GIT_REPOSITORY /home/djones/workspace/exceptions
CMAKE_ARGS "-DCMAKE_INSTALL_PREFIX=${CMAKE_INSTALL_PREFIX}"
)
So what's the purpose of INSTALL_DIR then?
You're right for the purpose of INSTALL_DIR, but you may have missed some steps.
According the cmake 2.8 doc about external project:
Install Step
The INSTALL_DIR is underneath the calling project’s
binary directory. Use INSTALL_DIR to specify a different location.
Note that in addition to setting INSTALL_DIR, you also have to pass
-DCMAKE_INSTALL_PREFIX or --prefix to the CMake or configure command. It is not used automatically in the configure step since not all
projects follow this convention.
# [INSTALL_DIR dir]
You can refer to the install directory in your configure command, for
example:
CONFIGURE_COMMAND SOURCE_DIR/configure --prefix=INSTALL_DIR
# [INSTALL_COMMAND cmd...]
CMake-based projects use ‘cmake--build’ to build the install target.
Other projects use ‘make install’. Use INSTALL_COMMAND to customize
the install step. Use INSTALL_COMMAND “” to omit the install step. The
install command executes with the working directory set to
.
So try to update your cmake command, or use the custom INSTALL_COMMAND feature.
I am trying to use CMake and CPack to build and package a Mac OS X application, but I can't figure out the correct way to include resources.
This is what my CMakeLists.txt looks like:
CMAKE_MINIMUM_REQUIRED(VERSION 2.8)
PROJECT(foo)
ADD_EXECUTABLE(foo foo.c foo.txt)
SET_TARGET_PROPERTIES(foo PROPERTIES MACOSX_BUNDLE TRUE)
SET_TARGET_PROPERTIES(foo PROPERTIES RESOURCE foo.txt)
INSTALL(TARGETS foo DESTINATION ".")
SET(CPACK_GENERATOR TGZ)
INCLUDE(CPack)
However, when I use it to build a package, foo.txt gets included twice: in the Resources directory of the bundle as expected, but also at the root:
$ cd build
$ cmake ..
$ make package
$ tar -xvzf foo-0.1.1-Darwin.tar.gz
x foo-0.1.1-Darwin/foo.app/Contents/Info.plist
x foo-0.1.1-Darwin/foo.app/Contents/MacOS/foo
x foo-0.1.1-Darwin/foo.app/Contents/Resources/foo.txt
x foo-0.1.1-Darwin/foo.txt
What am I doing wrong?
EDIT
For easier reading, here is what the final, working, CMakeLists.txt looks like (as per Josh's answer and my comment on it):
CMAKE_MINIMUM_REQUIRED(VERSION 2.8)
PROJECT(foo)
ADD_EXECUTABLE(foo foo.c foo.txt)
SET_TARGET_PROPERTIES(foo PROPERTIES MACOSX_BUNDLE TRUE)
SET_SOURCE_FILES_PROPERTIES(foo.txt PROPERTIES MACOSX_PACKAGE_LOCATION Resources)
INSTALL(TARGETS foo DESTINATION ".")
SET(CPACK_GENERATOR TGZ)
INCLUDE(CPack)
Removing the line * PROPERTIES RESOURCE foo.txt) should solve the problem.
Since you have included cpack in your cmake file, the generated TGZ will contain all of the files which would be installed with make install. In this case, you have
SET_TARGET_PROPERTIES(foo PROPERTIES MACOSX_BUNDLE TRUE)
which will build foo as an OS X application bundle (doc), and
SET_TARGET_PROPERTIES(foo PROPERTIES RESOURCE TRUE)
specifies foo.txt as a resource files (doc). With both of those PROPERTIES set, make install will create two versions of foo.txt. One in the bundle, foo.app/Contents/Resources/foot.txt, and one in the top level directory, foo.txt. Therefore, CPack will also generate those two versions of foo.txt.