We have multiple libraries in different folder, The main application needs to build those libraries in other folders and install them to output folder and then the main application needs to link to libraries to build executable.
I am able to build the libraries present in other folders using add_subdirectory() in a loop, but I am not able to install them to output folder by main cmake file. Could anyone help me out on this.
The main application needs to build those libraries in other folders and install them to output folder and then the main application needs to link to libraries to build executable.
It is not necessary in CMake to install libraries in order to link to them. You can build the libraries and have your main executable link to them without installing the libraries. When you need to install your application as a whole, you can install libraries along with the executable if needed i.e. if the libraries are shared ones and not static ones.
One example of how you can organize things: assume you have the following structure in your project:
CMakeLists.txt # root of project
|
|--lib
| |--CMakeLists.txt # library subproject
|
|--app
|--CMakeLists.txt # app subproject
Then your root CMakeLists.txt can look like this:
project(MyProject)
add_subdirectory(lib)
add_subdirectory(app)
The lib subproject's CMakeLists.txt can look like this:
project(MyLib)
set(SOURCES <...>) # specify library's sources
add_library(${PROJECT_NAME} ${SOURCES})
set(MyLib ${PROJECT_NAME} CACHE INTERNAL "")
The last line in the snippet above is aimed to make MyLib variable available everywhere within the project. I found this trick here and used it successfully in my projects. Maybe there are better options here, if anyone knows them, feel free to suggest.
The app's CMakeLists.txt can then look like this:
project(MyApp)
set(SOURCES <...>) # specify app's sources
add_executable(${PROJECT_NAME} ${SOURCES})
target_link_libraries(${PROJECT_NAME} ${MyLib})
I haven't covered the installation here but it's actually straightforward: if your libraries are static ones, you only need to install the executable using install TARGETS. If your libraries are shared ones, you need to install them along with the executable.
Related
When you install many packages through vcpkg (such as vcpkg install cairo), at the end of this process, you are told what find_package and target_link_libraries CMake commands to use in order to link to the package that was installed. And this works fine; you can even re-execute the install command to see these CMake commands again.
However, some packages installed through vcpkg don't have these. After installing Pango for example, there is no list of CMake commands to actually use the library. I found the target CMake file for find_package in several of the vcpkg package directories, but the Pango directory has no CMake file for the package.
For some reason, example code using Pango can still compile (ie: it can find Pango's headers), but it fails to link due to not linking to the right libraries.
So how is this supposed to work? Do I have to list the include directories, library directories, and library files through a variety of CMake interfaces for Pango? Or is there some alternative inclusion mechanism that takes care of the details like most other vcpkg packages?
Note that I'm using Visual Studio 2019's built-in CMake functionality to try to build with these.
find_package finds a particular kind of .cmake file that is usually shipped with vcpkg packages. These .cmake files do the work of setting include directories and libraries to link with.
As such, if a vcpkg package does not include such a file, you will need to essentially do the work that the file would have done. Fortunately, CMake and vcpkg know where the headers and library build files are for the various configurations. What you need to do is find those directories and libraries, then add them to your project (along with any other special compiler options that the package requires, which requires some familiarity with the package).
To find the include directory containing a library's header, use find_path to set a variable, giving it the name of a header file to search for. For example:
find_path(PANGO_INCLUDE_DIR pango/pango.h)
This header directory can then be set as part of the include path:
target_include_directories(project_name_here PRIVATE ${PANGO_INCLUDE_DIR})
Libraries are a bit harder, since you have to track down the full name (minus extensions) of the actual library. And if the package involves multiple libraries, you need to track down all of those which are applicable to you.
Given the name of a library or libraries of interest, you can find them one at a time with find_library, setting those libraries into variables:
find_library(PANGO_LIBRARY pango-1.0)
find_library(PANGOCAIRO_LIBRARY pangocairo-1.0)
You can then link with those libraries via target_link_libraries:
target_link_libraries(cairo_vcpkg PRIVATE
...
${PANGO_LIBRARY}
${PANGOCAIRO_LIBRARY}
)
Indeed, some packages installed via vcpkg do not export a .cmake file like Pango for you and SDL for me.
I want to clarify that I have been trying to use vcpkg for two days, I share with you the cmakelist.txt that I use on my side so that SDL works as if I had used find_package (SDL Required)
cmake_minimum_required(VERSION 3.16)
project(xxxx)
### Specify the C++ standard ###
set(CMAKE_CXX_STANDARD 11)
set(CMAKE_CXX_STANDARD_REQUIRED True)
set(CMAKE_MODULE_PATH ${CMAKE_SOURCE_DIR}/CMake)
### To find and use SDL ###
# find path of include and lib
find_path(SDL_INCLUDE_DIR SDL/SDL.h)
find_library(SDL_LIBRARY SDL)
# find pat of manual-link library
set (LIBRARIES_TO_LINK C:/dev/vcpkg/installed:/x64-windows/lib/manual-link)
find_library(SDL1_TEST SDLmain HINTS ${LIBRARIES_TO_LINK})
....
This can be considered as a follow-up to CMake MacOS X bundle with BundleUtiliies for Qt application
I want to create a MACOS bundle on CI which can be used by users for an open source project.
What I have:
Main executable
Updater executable
icon file
helper script calling updater then main
data files in a folder (translations etc, some generated at build time)
plugin shared libs
What I've done so far:
add MACOSX_BUNDLE to the executable
add icon to its sources and to RESOURCE property
set MACOSX_BUNDLE_* properties
install everything in a cross-platform way (regular install(TARGETS calls and install(FILES for the resources)
But now I'm stuck on how to get those into the bundle w/o to much manual work.
From the linked question I got something like this:
set(APPS "\$ENV{DESTDIR}\${CMAKE_INSTALL_PREFIX}/${PROJECT_NAME}.app")
set(LIBS )
set(DIRS "${CMAKE_BINARY_DIR}")
# Path used for searching by FIND_XXX(), with appropriate suffixes added
if(CMAKE_PREFIX_PATH)
foreach(dir ${CMAKE_PREFIX_PATH})
list(APPEND DIRS "${dir}/bin" "${dir}/lib")
endforeach()
endif()
install(CODE "include(BundleUtilities)
fixup_bundle(\"${APPS}\" \"${LIBS}\" \"${DIRS}\")")
But:
Why do I need to pass the *.app path manually? CMake does already know it, doesn't it?
LIBS should contain my plugins, shouldn't it? But what? Paths? Target names?
DIRS is also a mystery to me. No documentation even in CMake 3.12 (I'm still using 2.8.12 though :( )
How to add my generated and regular data files? Probably same or similar to the icon? But what about the generated ones?
Help, pointers to examples, full CMakeLists doing that etc. very welcome.
Note: I'm cross-compiling from linux on the CI and NOT using Qt so e.g. macdeployqt or so is out of question.
Just got stuck on the same issue and google brought me here.
This worked for me:
set(CUR_TARGET myappname)
add_executable(${CUR_TARGET} MACOSX_BUNDLE ${MY_SRC})
set_target_properties(${CUR_TARGET} PROPERTIES
BUNDLE True
MACOSX_BUNDLE_GUI_IDENTIFIER my.domain.style.identifier.${CUR_TARGET}
MACOSX_BUNDLE_BUNDLE_NAME ${CUR_TARGET}
MACOSX_BUNDLE_BUNDLE_VERSION "0.1"
MACOSX_BUNDLE_SHORT_VERSION_STRING "0.1"
MACOSX_BUNDLE_INFO_PLIST ${CMAKE_SOURCE_DIR}/cmake/customtemplate.plist.in
)
The file customtemplate.plist.in is based on the cmake template from the cmake dir subfolder at your_cmake_install_dir/share/cmake/Modules/MacOSXBundleInfo.plist.in
I have been trying to build RPM packages for libc++ 3.3 on a RHEL 6.4 box. I need both static and shared libraries. So, I learned some basics of cmake and then modified the bundled CMakeList.txt. Got that part to work.
But since in RHEL 6.x, all 64-bit libraries should go to /usr/lib64 instead of /usr/lib, I have been attempting to use the following to get the job done:
(A) During building, I use
SET(LIBRARY_OUTPUT_PATH ${PROJECT_BINARY_DIR}/lib${LIB_SUFFIX})
to have all library files (*.so* and *.a) located in lib64 rather than lib.
(B) Using a ADD_LIBRARY... command as shown below
ADD_LIBRARY(c++ STATIC ...
together with
set_target_properties(c++ PROPERTIES
ARCHIVE_OUTPUT_DIRECTORY ${PROJECT_BINARY_DIR}/lib${LIB_SUFFIX})
INSTALL(TARGETS c++
ARCHIVE DESTINATION lib${LIB_SUFFIX})
to get the static library installed in /usr/lib64.
(C) In addition, with
INSTALL(FILES ${PROJECT_BINARY_DIR}/lib${LIB_SUFFIX}/libc++.so DESTINATION lib${LIB_SUFFIX})
INSTALL(FILES ${PROJECT_BINARY_DIR}/lib${LIB_SUFFIX}/libc++.so.1 DESTINATION lib${LIB_SUFFIX})
INSTALL(FILES ${PROJECT_BINARY_DIR}/lib${LIB_SUFFIX}/libc++.so.1.0 DESTINATION lib${LIB_SUFFIX})
to have shared libary also installed in /usr/lib64 too.
But a copy of the shared library is still installed in /usr/lib in the resulting RPM. How can I prevent it?
If I were to write a RPM spec file, the _libdir macro automatically handles this. With cmake, given the fact that I am still new to it, I would appreciate a hint/pointer as to the right directive to use.
Actually, with a helpful person in the cmake mailing list, I am now able to rid of the %dir /usr/lib in the generated spec file. It's actually quite simple: just cd to $CMAKE_SOURCE_DIR/lib and edit the CMakeLists.txt there. Append ${LIB_SUFFIX} to the two install DESTINATIONs. Regenerate the Makefile in the build subdirectory, and then make && make package. All library files go into /usr/lib64 as desired.
What I can see:
1) There's a missing space in ARCHIVE_OUTPUT_DIRECTORY${PROJECT_BINARY_DIR}/lib${LIB_SUFFIX}), should be ARCHIVE_OUTPUT_DIRECTORY ${PROJECT_BINARY_DIR}/lib${LIB_SUFFIX})
2) When are your .so files going to be build if you use ADD_LIBRARY(c++ STATIC ...?
I'm using CMake on Windows to build test suite based on Boost.Test. As I'm linking to Boost.Test dynamically, my executable needs to be able to find the DLL (which is under ../../../boost/boost_1_47/lib or something like that relative to the executable).
So I need to either copy the DLL into the folder where the executable is, or make it findable in some other way. What's the best way to achieve this with CMake?
-- Additional info --
My CMakeLists.txt has this Boost related configuration at the moment:
set(Boost_ADDITIONAL_VERSIONS "1.47" "1.47.0")
set(BOOST_ROOT "../boost")
find_package(Boost 1.47 COMPONENTS unit_test_framework REQUIRED)
include_directories(${Boost_INCLUDE_DIR})
link_directories(${Boost_LIBRARY_DIR})
add_executable(test-suite test-suite.cpp)
target_link_libraries(test-suite ${Boost_LIBRARIES})
Assuming you are running your tests by building the RUN_TESTS target in Visual Studio:
I always add .../boost/boost_1_47/lib to my command PATH environment variable, so the boost unit_test_framework dlls can be found at run time. That's what I recommend.
If for some reason changing your PATH is not possible, you could copy the files with cmake.
(untested)
get_filename_component(LIBNAME "${Boost_UNIT_TEST_FRAMEWORK_LIBRARY_RELEASE}" NAME)
add_custom_command(TARGET test-suite POST_BUILD
COMMAND ${CMAKE_COMMAND} -E copy "${Boost_UNIT_TEST_FRAMEWORK_LIBRARY_RELEASE}" "${CMAKE_CURRENT_BINARY_DIR}/${LIBNAME}"
)
3. If you are NOT only running the tests at build time (as I was assuming above), then you need a series of INSTALL commands, like Hans Passant suggested. In your snippet you don't have an INSTALL command for your executable; so even your executable won't end up "in the executable folder". First add a cmake INSTALL command to put your executable someplace in response to the cmake INSTALL target. Once you have that working, we can work on figuring out how to add another INSTALL command to put the boost unit_test_framework library into the same location. After that, if you want to make an installer using CPACK, the library will automatically be installed with the executable.
I ended up using the install command to copy the Boost DLL over to the executable's folder:
get_filename_component(UTF_BASE_NAME ${Boost_UNIT_TEST_FRAMEWORK_LIBRARY_RELEASE} NAME_WE)
get_filename_component(UTF_PATH ${Boost_UNIT_TEST_FRAMEWORK_LIBRARY_RELEASE} PATH)
install(FILES ${UTF_PATH}/${UTF_BASE_NAME}.dll
DESTINATION ../bin
CONFIGURATIONS Release RelWithDebInfo
)
get_filename_component(UTF_BASE_NAME_DEBUG ${Boost_UNIT_TEST_FRAMEWORK_LIBRARY_DEBUG} NAME_WE)
install(FILES ${UTF_PATH}/${UTF_BASE_NAME_DEBUG}.dll
DESTINATION ../bin
CONFIGURATIONS Debug
)
I have a very similar problem, but the solution presented here is not really satisfactory.
Like the original poster, I want to run unit tests based on boost::test.
I have multiple test projects, one for each mayor component of our product.
Having to run the install target prior to every test means recompiling the whole thing just to run the tests belonging to a core component. That's what I want to avoid.
If I change something in a core component, I want to compile that core component and the associated tests. And then run the tests. When the tests succeed, only then do I want to compile and eventually install the rest of it.
For running the tests in the debugger, I found some very useful cmake scripts at :
https://github.com/rpavlik/cmake-modules
With this, I can specify all the directories of the required dlls, and the PATH environment variable is set for the new process:
# for debugging
INCLUDE(CreateLaunchers)
create_target_launcher(PLCoreTests
ARGS "--run-test=Core1"
RUNTIME_LIBRARY_DIRS ${PL_RUNTIME_DIRS_DEBUG} ${PROJECT_BINARY_DIR}/bin/Debug
WORKING_DIRECTORY ${PL_MAIN_DIR}/App/PL/bin
)
Where ${PL_RUNTIME_DIRS_DEBUG} contains the directories where the dlls from boost and all the other libraries can be found.
Now I'm looking for how I can achieve something similar with ADD_CUSTOM_COMMAND()
Update:
ADD_CUSTOM_COMMAND() can have multiple commands that cmake writes into a batch file. So, you can first set the path with all the runtime directories, and then execute the test executable. To be able to easily execute the tests manually, I let cmake create an additional batch file in the build directory:
MACRO(RunUnitTest TestTargetName)
IF(RUN_UNIT_TESTS)
SET(TEMP_RUNTIME_DIR ${PROJECT_BINARY_DIR}/bin/Debug)
FOREACH(TmpRuntimeDir ${PL_RUNTIME_DIRS_DEBUG})
SET(TEMP_RUNTIME_DIR ${TEMP_RUNTIME_DIR} ${TmpRuntimeDir})
ENDFOREACH(TmpRuntimeDir)
ADD_CUSTOM_COMMAND(TARGET ${TestTargetName} POST_BUILD
COMMAND echo "PATH=${TEMP_RUNTIME_DIR};%PATH%" > ${TestTargetName}_script.bat
COMMAND echo ${TestTargetName}.exe --result_code=no --report_level=no >> ${TestTargetName}_script.bat
COMMAND ${TestTargetName}_script.bat
WORKING_DIRECTORY ${CMAKE_RUNTIME_OUTPUT_DIRECTORY}/Debug
)
ENDIF(RUN_UNIT_TESTS)
ENDMACRO()
With this, the unit tests catch the errors as soon as possible, without having to compile the whole lot first.
I have a project organized as follows:
include/
src/
share/myprogram/
where share/myprogram/ contains resources.
My program is accessing these resources using relative paths. The executable expects to find them in ../share/myprogram/.
I would like when I run:
mkdir build
cd build
cmake ..
make
to have the following to happen:
make a bin directory
compile and put the executable in bin/
copy the share directory in the build directory
I am looking for a clean way of doing this. Ideally, I would like CMake to be aware of the resources as resources.
I know that I could use a copy custom command. Is this the only way to achieve this?
Bonus
If the resources could appear under Resources in Xcode when using the Xcode generator, and the copy be a clean copy phase under the mybin target, that would be awesome (and that's what I mean by CMake being aware of the resources as resources.)
Update:
What I have thus far:
set(CMAKE_RUNTIME_OUTPUT_DIRECTORY ${PROJECT_BINARY_DIR}/bin)
add_executable(mybin ${Headers} ${Sources})
add_custom_target(
Resources ALL
${CMAKE_COMMAND} -E copy_directory ${PROJECT_SOURCE_DIR}/share ${PROJECT_BINARY_DIR}/share
SOURCES ${Resources}
)
You may use Configure_file for copying files from source dir to binary dir. it has parameter Copyonly.
I am doing a unix command line tool, I am not doing a Mac OS X bundle and Xcode's resource folder is only for bundle resources so forget the bonus.
I realized that I wasn't doing things correctly.
Using a relative path to access a resource is not reliable since the program can be executed from anywhere.
What I did is to look for resources in a hierarchy of folder, starting from user specified, to environment variable, to relative directories and finally to standard unix directories.
So actually, the copy phase during the build is not necessary anymore. Only the installation matters and that is fairly easy:
install(DIRECTORY share/ DESTINATION share)
FYI, I kept my custom_target as is since I like having resources visible in Xcode, and calling it Resources makes it pretty :)