Building a library with an executable that uses it - windows

I have a library "lib" and an executable "demo".
The issue I'm having is that "demo" can't get lib_INCLUDES and lib_LIBS lib variables, set by "lib". I want them set because in demo.h I do #include <lib.h> and it fails to find the include. I want CMake to make lib.h a global include, i.e. pass -I /path/to/the/dir/with/lib.h/ to the compiler.
Source tree:
- src/
- CMakeLists.txt
- lib/
- CMakeLists.txt
- lib.cpp
- lib.h
- demo/
- CMakeLists.txt
- demo.cpp
- demo.h
src/CMakeLists.txt
cmake_minimum_required(VERSION 2.8)
project(test)
add_subdirectory(lib)
add_subdirectory(demo)
src/lib/CMakeLists.txt
add_library(lib SHARED lib.h lib.cpp)
target_include_directories(lib ${CMAKE_CURRENT_SOURCE_DIR})
# defined for later use in src/demo/CMakeLists.txt
set(lib_INCLUDES ${CMAKE_CURRENT_SOURCE_DIR})
set(lib_LIBS lib)
src/demo/CMakeLists.txt
include_directories(${lib_INCLUDES})
add_executable(demo demo.h demo.cpp)
target_link_libraries(demo ${lib_LIBS})
# empty! why?
message(STATUS ${lib_INCLUDES})
Tell me how "demo" can access lib_INCLUDES and lib_LIBS libraries set by "lib", they seem to be empty in src/demo/CMakeLists.txt.
I don't want src/demo/CMakeLists.txt contain paths to "lib", only src/lib/CMakeLists.txt should know details of "lib" and it should define nice variables for use in src/demo/CMakeLists.txt that hide all those details.
Please include a working CMakeLists.txt in your answer, if possible.

Please read carefully documentation of SET command. Your variable lib_INCLUDES has local scope to lib\CMakeLists.txt, so for example you can CACHE it.
Better way is to populate INTERFACE_INCLUDE_DIRECTORIES of lib by
target_include_directories(lib INTERFACE ${CMAKE_CURRENT_SOURCE_DIR})
so the target_link_libraries automatically appends lib's include directories.

Related

Necessity of include_directories command in cmake project

I'm following a tutorial on CMake and I have problems understanding the necessity of using the 'include_directories' command at one point.
Let me explain the project first:
In my working directory I have:
- a main.cpp function, a CMakeLists.txt(the main one), a configuration file, a 'MathFunction' directory and a 'build' directory
In the MathFunction directory I have:
- a CMakeLists.txt file that will be invoked by the main one
- A file 'mysqrt.cxx' that contains the implementation of a function which will be used in 'main.cpp' application
- A 'MathFunctions.h' header file that contains the prototype of that function
In the CMakeLists from 'MathFunction' directory I'm creating a library using code from 'mysqrt.cxx' like this:
add_library(MathFunctions mysqrt.cxx)
This snippet is a part of my main CMake code:
# add the MathFunctions library?
#
if (USE_MYMATH)
include_directories ("${PROJECT_SOURCE_DIR}/MathFunctions") # WHY DO WE NEED THIS
add_subdirectory (MathFunctions)
set (EXTRA_LIBS ${EXTRA_LIBS} MathFunctions)
endif (USE_MYMATH)
add_executable(Tutorial tutorial.cxx)
target_link_libraries (Tutorial MathFunctions)
Now I do not understand why I need too add that 'include_directories' command in order to use the library? Shouldn't it be enough that the last command 'target_link_libraries' links the already created executable and libraries togheter so there would be no need to also include_directories?
Thank you for reading and I'm sorry if I have not explained it very well but I hope you will understand what I mean :D
Command include_directories sets directories for header files (.h) to be searched. Linking (target_link_libraries) with a library basically specifies only a library file (.so, .dll or other type). As you see, these are different things.
When linking executable with a library target, CMake propagates (more precisely, "consumes") some properties of that library target to the executable. Among these properties there is INTERFACE_INCLUDE_DIRECTORIES property, which adds include directories to the executable.
So, when a library target has INTERFACE_INCLUDE_DIRECTORIES property correctly being set, you don't need to explicitly specify include directories for executable:
MathFunctions/CMakeLists.txt:
add_library(MathFunctions mysqrt.cxx)
# Among other things, this call sets INTERFACE_INCLUDE_DIRECTORIES property.
target_include_directories(MathFunctions PUBLIC ${CMAKE_CURRENT_SOURCE_DIR})
CMakeLsits.txt:
add_executable(Tutorial tutorial.cxx)
# This also propagates include directories from the library to executable
target_link_libraries (Tutorial MathFunctions)
Note, that using simple
# This *doesn't* set INTERFACE_INCLUDE_DIRECTORIES property.
include_directories(${CMAKE_CURRENT_SOURCE_DIR})
in MathFunctions/CMakeLists.txt doesn't imply propagating include directories to the linked executable.

How to control subdirectory compiling order of cmake?

This is my CMakeLists.txt:
ADD_SUBDIRECTORY(third)
ADD_SUBDIRECTORY(utils)
ADD_SUBDIRECTORY(rpc)
But the directory 'rpc' will be compiled before directory 'utils', actually the 'rpc' is depends on 'utils', so I will get a link error.
How can I make the 'rpc' compiling after 'utils'?
Thanks.
When you use target_link_libraries() function and pass it other target name, CMake automatically sets this target as a dependency. You can also use add_dependencies() to specify dependencies manually.
Also note that order of sources compilation have nothing to do with your problem. Link errors (i guess, you are seeing "undefined reference" ones) are because you aren't linking your targets properly.
if the 'rpc' is depends on 'utils':
utils CMAKELISTS.txt
project(utils)
add_library (utils SHARED ${PROJECT_SOURCE_LIST})
rpc CMAKELISTS.txt
project(rpc)
add_library (rpc SHARED ${PROJECT_SOURCE_LIST})
# must add this command to scan dependencies of target rpc
add_dependencies (rpc utils)
target_link_libraries (${TEST_SOURCE_FILE_NAME} libutils.so)
I have the same question with you.
I have open source libs —— jthread and jrtplib. I want to build them by a main CmakeList.text so I make a folder like:
cpp
├─jrtplib
│ ├─src
│ └─CMakeFiles.txt
├─jthread
│ ├─src
│ └─CMakeFiles.txt
└─CMakeFiles.txt
and cpp/CMakeFiles.txt like:
cmake_minimum_required (VERSION 3.8)
set(JTHREAD_ENABLED 1)
# 包含子项目。
add_subdirectory ("jthread")
add_subdirectory ("jrtplib")
but build error, it build jrtplib first, I think "jr" > "jt", so build jrtplib first, and it can't find libjthread.so , so target_link_libraries error
I find a solution :
cmake_minimum_required (VERSION 3.8)
# ↓↓↓↓↓↓↓↓ attention ↓↓↓↓↓↓↓↓
set(CMAKE_ARCHIVE_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR})
set(CMAKE_LIBRARY_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR})
set(CMAKE_RUNTIME_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR})
# ↑↑↑↑↑↑↑↑ attention ↑↑↑↑↑↑↑↑
set(JTHREAD_ENABLED 1)
# copy jthread/src/*.h to C:/thirdParty/include/jthread
set(JTHREAD_INCLUDE_DIRS "C:/thirdParty/include")
set(JTHREAD_LIBRARIES "libjthread.so")
# 包含子项目。
add_subdirectory (jthread)
add_subdirectory (jrtplib)
set xx_OUTPUT_DIRECTORY can set library build in main cmake_build folder, so jrtplib can find libjthread.so .
build success ...
I am assuming that the project named "third" is independent however "utils" depends upon "rpc". Try the following code for a sequential build
ADD_SUBDIRECTORY(third)
ADD_SUBDIRECTORY(utils "${CMAKE_CURRENT_BINARY_DIR}/utils_build")
ADD_SUBDIRECTORY(rpc "${CMAKE_CURRENT_BINARY_DIR}/rpc_build")
this will make a "_build" directory in your given build directory. and will copy the binaries there. For more information try
cmake --help-command ADD_SUBDIRECTORY

CMake Hierarchical Project Management Without Abusing Libraries

I have a project where there's only a handful of logical groupings for generating static libraries. However for convenience I want to have the library's source code to be managed with more granular folders.
Currently the only way I know to do this in CMake without having a library for each folder is to just list files as you would normally in with their relative paths:
add_library(SystemAbstraction STATIC "Some/Path/File.cpp")
However I can see this getting unwieldy as the project grows in size with all the different paths.
I tried to see if I could have a CMakeLists.txt in each folder and just use a variable in the base CMakeLists.txt when adding library dependencies. But it seems that add_subdirectory doesn't also import variables?
For expanding the scope of a variable inside a subdirectory, use the PARENT_SCOPE option of set. For example, you can test that if you have
# CMakeLists.txt
set(SRCS main.c)
add_subdirectory(foo)
message(${SRCS})
in the root directory and
# foo/CMakeLists.txt
set(SRCS ${SRCS} foo.c PARENT_SCOPE)
in a subdirectory then it will print main.c foo.c, i.e., the variable is correctly imported into the base CMakeLists.txt.
An option would be to use the object library feature of CMake. You still can but doesn't need to organise your CMake script into subdirectories:
add_library(lib1 OBJECT <srcs>)
add_library(lib2 OBJECT <srcs>)
...
add_library(mainlib $<TARGET_OBJECTS:lib1> $<TARGET_OBJECTS:lib2>)
You can set different compile flags for each object library:
target_include_directories(lib1 PRIVATE incl-dir-for-lib1)
target_compile_definitions(lib2 PRIVATE def-for-lib2)
You still need to set link libraries on your main library:
target_link_libraries(mainlib PRIVATE deps-of-lib1 deps-of-lib2)
Related documentation: Object Libraries

Can't compile executable with CMake

I started with the following directory structure:
project
exec
executable.exe
lib
src
include
config
<cmake-generated config file>
I created the library in the lib/src folder by using a CMakefile in the lib/src folder. The exe would compile.
Then, I moved my CMakeFile up to /lib, making sure to change the source file paths to /src/*
Now, when I try to compile, all my libraries compile and link fine, but when I try to link the executable, I get /usr/bin/ld: cannot find -lconfig.
Does anyone have any idea why this happens or how to fix it?
Here is some of my code:
./CMakeLists.txt:
include_directories(config)
SET(EXECUTABLE_OUTPUT_PATH ${PROJECT_BINARY_DIR}/bin)
SET(LIBRARY_OUTPUT_PATH ${PROJECT_BINARY_DIR}/lib)
ADD_SUBDIRECTORY(libs) #library sources
ADD_SUBDIRECTORY(exec) #executable sources
CONFIGURE_FILE(${core_SOURCE_DIR}/config/config.h.in
${core_SOURCE_DIR}/config/config.h)
./libs/CMakeLists.txt:
file(GLOB src ...)
file(GLOB header ...)
add_library(lib ${src} ${header})
./exec/CMakeLists:
add_executable(executable executable.cpp)
link_directories(${core_SOURCE_DIR}/lib) #not sure if this is required
target_link_libraries(executable ${lots_of_libs})
Every library in lots_of_libs can be found as a .a file in the lib directory
One problem, probably not risolutive, is this:
link_directories(${core_SOURCE_DIR}/lib) #not sure if this is required
should be:
link_directories(${PROJECT_BINARY_DIR}/lib)
or:
link_directories(${LIBRARY_OUTPUT_PATH})
Anyway, normally you wouldn't need to add to your link_directories the path to a library that is built within the project, even if you have specified a different LIBRARY_OUTPUT_PATH

How to Generate Windows DLL versioning information with CMake

I'm using CMake to build a shared library, however for the Windows DLL I need the versioning information, like:
FileDescription
FileVersion
InternalName
LegalCopyright
OriginalFilename
ProductName
ProductVersion
So far, all I have are the VERSION and SOVERSION properties, but these don't seem to correlate to the FileVersion information I was expecting.
set(LIC_TARGET MySharedLib)
add_library(${LIC_TARGET} SHARED ${SOURCES} )
SET_TARGET_PROPERTIES(${LIC_TARGET}
PROPERTIES
VERSION ${MY_PRODUCT_NUMBER}.${MY_PRODUCT_VERSION}.${MY_BUILD_NUMBER}
SOVERSION ${MY_PRODUCT_NUMBER})
I've found manual methods (see example at the bottom) but would prefer to contain this within CMake.
Help?
You could use your CMake variable values in conjunction with a version.rc.in file and the configure_file command.
// version.rc.in
#define VER_FILEVERSION #MY_PRODUCT_NUMBER#,#MY_PRODUCT_VERSION#,#MY_BUILD_NUMBER#,0
#define VER_FILEVERSION_STR "#MY_PRODUCT_NUMBER#.#MY_PRODUCT_VERSION#.#MY_BUILD_NUMBER#.0\0"
#define VER_PRODUCTVERSION #MY_PRODUCT_NUMBER#,#MY_PRODUCT_VERSION#,#MY_BUILD_NUMBER#,0
#define VER_PRODUCTVERSION_STR "#MY_PRODUCT_NUMBER#.#MY_PRODUCT_VERSION#.#MY_BUILD_NUMBER#\0"
//
// ...along with the rest of the file from your "manual methods" reference
And then, in your CMakeLists.txt file:
# CMakeLists.txt
set(MY_PRODUCT_NUMBER 3)
set(MY_PRODUCT_VERSION 5)
set(MY_BUILD_NUMBER 49)
configure_file(
${CMAKE_CURRENT_SOURCE_DIR}/version.rc.in
${CMAKE_CURRENT_BINARY_DIR}/version.rc
#ONLY)
set(LIC_TARGET MySharedLib)
add_library(${LIC_TARGET} SHARED ${SOURCES}
${CMAKE_CURRENT_BINARY_DIR}/version.rc)
# Alternatively you could simply include version.rc in another rc file
# if there already is one in one of the files in ${SOURCES}
I'm had same problem and have automated version generation for my projects.
You need three files from github:
generate_product_version.cmake
VersionInfo.in
VersionResource.rc
Put it in cmake subdirectory of your project and make sure to include it to CMAKE_MODULE_PATH like:
set(CMAKE_MODULE_PATH ${CMAKE_MODULE_PATH} ${CMAKE_SOURCE_DIR}/cmake)
Then before add_executable() or add_library(SHARED) your target, use:
include(generate_product_version)
generate_product_version(
VersionFilesOutputVariable
NAME "My Great Project"
ICON ${PATH_TO_APPLICATION_ICON}
VERSION_MAJOR 1
VERSION_MINOR 3
VERSION_PATCH ${BUILD_COUNTER}
VERSION_REVISION ${BUILD_REVISION}
)
Full list of supported resource strings see in generate_product_version.cmake.
VersionInfo.h and VersionResource.rc will be generated to cmake binaries folder. Variable VersionFilesOutputVariable will hold paths to these files. Just add this list to your target:
add_executable(MyGreatProject ${your-target-sources} ${VersionFilesOutputVariable})
UPDATE: Corrected generate_product_version script parameters from VERSION_PATH
to VERSION_PATCH.
There is an even easier way than the accepted answer. It does not involve transforming an input resource.rc.in. Simply create a generic version.rc file as described here and then from your CMakeLists.txt do this:
#CMakeLists.txt
add_definitions(-DVER_COMPANYNAME_STR="MyCompany")
add_definitions(-DVER_FILEVERSION_STR="1,1,0.0")
# ...
# add all the other defines here
set(LIC_TARGET MySharedLib)
add_library(${LIC_TARGET} SHARED ${SOURCES} version.rc)
This has the added benefit that the defines are accessible from your source code as well, so you have programmatic access to your version.

Resources