I am using CMAKE to build a quite large project consisting of many libraries and executables. There is something wrong with how I specify library-library dependencies, and things do not work fully as wanted. Schematically my project looks like this:
CMakeLists.txt
lib1/src/CMakeLists.txt
lib2/src/CMakeLists.txt
app/src/CMakeLists.txt
I.e. I have two libraries lib1 and lib2 where lib2 depends on lib1 and app depends on both lib1 and lib2. I build libraries using both shared and static linking:
add_library(lib1_static STATIC lib1_src)
add_library(lib1_shared SHARED lib1_src)
set_target_properties( lib1_static PROPERTIES OUTPUT_NAME lib1)
set_target_properties( lib1_shared PROPERTIES OUTPUT_NAME lib2)
To ensure that the dependies are satisfied I have target_link_libraries() as:
#lib2/src/CMakeLists.txt:
target_link_libraries( lib2_shared lib1_shared )
target_link_libraries( lib2_static lib1_static )
And for the app:
#app/src/CMakeLists.txt
target_link_libraries( app_static lib2_static ) # <- No explicit dependance on lib1
target_link_libraries( app_shared lib2_shared )
Now - the problem is that when I make a fresh build it compiles for quite a long time, but when creating the liblib2.so file the error message:
make[2]: *** No rule to make target 'lib1/src/liblib1.so' needed by 'lib2/src/liblib2.so'. Stop.
appears. If I then just issue a new make command - things will build successfully. So it seems I have not managed to configure the dependencies correctly? Note that the make output from the first build attempt shows:
Linking C shared library liblib1.so
So the build itself has suceeded - but it seems like the build will not use the liblib1.s0 file created during this build instance to resolve the lib2 dependencies?
I have tried - and removed again - several varietes of link_directories() and target_depends() without success.
It seems, CMake got confused by usage of
set_target_properties( lib1_static PROPERTIES OUTPUT_NAME lib1)
Try this:
target_link_libraries( lib2_shared lib1 )
or remove these property settings.
I was using CMake version 2.6 - I upgraded to CMake 2.8 and then it worked for me.
Related
Here is my source code structure:
cd my_git_repo/
CMakeLists.txt
src/
main.cpp
mylibrary/
a.hpp
b.hpp
a.cpp
b.cpp
CMakeLists.txt
Root CMakeLists.txt:
cmake_minimum_required(VERSION 3.9)
project(myexe CXX)
add_subdirectory(src/mylibrary)
find_library(mylib NAMES mylibrary.so PATHS "./src/mylibrary/mylibrary.so")
add_executable(myexe src/main.cpp)
target_link_libraries(myexe ${mylib})
mylibrary/CMakeLists.txt is very simple. It builds a shared library and installs them.
Ideally, mylibrary target should be built and installed before myexe is built. But this doesn't happen. mylibrary is built followed by myexe. Installation happens later. Because of this, find_library fails. pkg_check_modules() works for other shared libraries but fails here because of the same reason.
I appreciate your help.
Edit:
This question differs from the duplicate because the answers posted to that question seem to be statically linking the library target_link_libraries(game engine). I want to dynamically link the .so library.
The idea in CMake is to build modules and then link them together.
You haven't shared the CMakeLists.txt for my library, so we cannot tell what it is doing. However, assuming that it is something like:
ADD_LIBRARY(mylibrary
file1.cpp
file2.cpp
)
Since you specified that you want mylibrary to always be linked as shared, you need to tell CMake that as well by either setting BUILD_SHARED_LIBS TO ON or by specifying SHARED in add_library:
ADD_LIBRARY(mylibrary SHARED
file1.cpp
file2.cpp
)
This is your library module. We will keep it simple for now and not worry about packing the library archive and installation here.
Now, back to your main CMakeLists.txt and how to make myexe consume it. Since you have already add_subdirectory(src/mylibrary), CMake knows about mylibrary. So simply link it using the module name. There is no need to find_library as you have already defined the module.
add_executable(myexe src/main.cpp)
target_link_libraries(myexe mylibrary)
This should suffice.
Do note, however, this is a very basic example to explain to you how CMake is designed to work. If you aren't building the library, and it is already installed, you would call find_library. Modern CMake is a bit more sophisticated and uses generator expressions, so be sure to read up on that as you progress to more complex projects.
I have this CMakeLists.txt file:
cmake_minimum_required(VERSION 3.8)
include(${CMAKE_CURRENT_SOURCE_DIR}/src/Something.cmake)
add_executable(execute main.cpp)
add_dependencies(somethingInterface Something)
add_dependencies(execute somethingInterface)
include_directories(
${CMAKE_CURRENT_SOURCE_DIR}/src
)
target_compile_options(execute
PRIVATE
-std=c++11
-g
)
add_library(library SHARED IMPORTED)
set_target_properties(library PROPERTIES IMPORTED_LOCATION ${CMAKE_BINARY_DIR}/library.so)
target_link_libraries(execute
PRIVATE
library
)
The library shared imported will be created in file Something.cmake, but tt must be built first.
It was a add_custom_command(TARGET POST_BUILD...) in file Something.cmake.
I don't have any problem in using CMake builds here, but when I am using Ninja there an error.
ninja: error: 'library.so', needed by 'execute', missing and no known rule to make it
Or do you have any suggestion on how can you do this?
I think Ninja has a requirement that "library.so" must exist first, but CMake it is different. It checks whether the library is there at runtime.
There is indeed a divergence between the way Make and Ninja handle imported targets. What works with Make, may sometimes not work with Ninja.
In particular, the following lines of code work with Make, but not with Ninja:
ExternalProject_Add(extProject
GIT_REPOSITORY <GIT_URL>
CMAKE_CACHE_ARGS "-
DCMAKE_INSTALL_PREFIX:STRING=${CMAKE_INSTALL_PREFIX}"
)
add_library(extLib SHARED IMPORTED)
add_dependencies(extLib extProject)
set_target_properties(extLib
PROPERTIES IMPORTED_LOCATION ${CMAKE_INSTALL_PREFIX}/lib/libext.so
)
target_link_libraries(project extLib)
The CMake configure step will work fine, but at build time Ninja will complain:
ninja: error: '/path/to/libext.so', needed by 'project', missing and no known rule to make it
But this will work fine with Make.
You need to specify the library as a byproduct of the ExternalProject_Add comment as mentioned by Tsyvarev, as ExternalProject runs at build time.
The following works fine for me:
ExternalProject_Add(extProject
GIT_REPOSITORY <GIT_URL>
CMAKE_CACHE_ARGS "-
DCMAKE_INSTALL_PREFIX:STRING=${CMAKE_INSTALL_PREFIX}"
BUILD_BYPRODUCTS ${CMAKE_INSTALL_PREFIX}/lib/libext.so
)
add_library(extLib SHARED IMPORTED)
add_dependencies(extLib extProject)
set_target_properties(extLib
PROPERTIES IMPORTED_LOCATION ${CMAKE_INSTALL_PREFIX}/lib/libext.so
)
target_link_libraries(project extLib)
Given this cmake sample project:
lib1/CMakeLists.txt:
add_library(lib1 src1.cpp)
target_include_directories(lib1 PUBLIC include)
lib2/CMakeLists.txt:
add_library(lib2 src2.cpp)
target_include_directories(lib2 PUBLIC include)
target_link_libraries(lib2 PRIVATE lib1)
lib3/CMakeLists.txt:
add_library(lib3 src3.cpp)
target_include_directories(lib3 PUBLIC include)
target_link_libraries(lib3 PRIVATE lib2)
All .cpp and .h files are dummy files with no dependency between them.
From what I understood from the documentation, adding a "PRIVATE" target library from lib2 to lib1 means that lib1 include directory should not be added when compiling lib3. However, when launching compiling this using cmake (3.3.2) and "make VERBOSE=1", command line to compile "src3.cpp" contains "-I/.../lib1/include":
c++ -I/.../lib3/include -I/.../lib2/include -I/.../lib1/include -o .../src3.cpp.o -c /.../lib3/src3.cpp
What did I get wrong ?
From what I understood from the documentation, adding a "PRIVATE"
target library from lib2 to lib1 means that lib1 include directory
should not be added when compiling lib3.
Your assumptions are correct.
However, due to legacy reasons in how properties propagate between dependent targets, this correct behavior is deactivated when specifying an old version in cmake_minimum_required.
By changing the version to 3.0 or later, you will get the correct behavior:
cmake_minimum_required(VERSION 3.0)
...
See also this thread on the CMake mailing list.
I have a subdirectory with a CMakeLists.txt which should compile a library using make and export the result as an imported library to the parent directory:
set(static_lib ${CMAKE_CURRENT_BINARY_DIR}/lib/mylib.a)
add_custom_command(
WORKING_DIRECTORY ${CMAKE_CURRENT_SOURCE_DIR}
OUTPUT ${static_lib}
COMMAND make
COMMAND make install PREFIX=${CMAKE_CURRENT_BINARY_DIR}
)
add_custom_target(compile_mylib DEPENDS ${static_lib})
add_library(mylib STATIC IMPORTED)
set_property(TARGET mylib PROPERTY IMPORTED_LOCATION ${static_lib})
add_dependencies(mylib compile_mylib)
The CMakeLists.txt in the parent directory looks like this:
add_subdirectory(deps/mylib)
add_executable(mybin source.c)
target_link_libraries(mybin mylib)
On OSX this works just fine - but if I compile the same on Ubuntu it seems to ignore the subdirectory's CMakeLists and complains:
/usr/bin/ld.bfd.real: cannot find -lmylib
I'm using Clang for compilation.
The solution is to add GLOBAL to your add_library call so that it is visible to the parent CMakeLists.txt
you can try this:
find_library(MYLIB mylib.a ${CMAKE_CURRENT_BINARY_DIR}/lib)
then set your link libraries:
target_link_libraries(mybin ${MYLIB})
should be work.
Let's say there's the following directory structure:
projects
|
+--lib1
| |
| +-CMakeFiles.txt
|
+--lib2
| |
| +-CMakeFiles.txt
|
+--test
|
+-CMakeFiles.txt
lib1/CMakeFiles.txt:
cmake_minimum_required(VERSION 2.0)
add_library(lib1 STATIC lib1.cpp)
lib2/CMakeFiles.txt:
cmake_minimum_required(VERSION 2.0)
add_subdirectory(../lib1 ${CMAKE_CURRENT_BINARY_DIR}/lib1)
add_library(lib2 STATIC lib2.cpp)
target_link_libraries(lib2 lib1)
test/CMakeFiles.txt:
cmake_minimum_required(VERSION 2.0)
project(test)
add_subdirectory(../lib1 ${CMAKE_CURRENT_BINARY_DIR}/lib1)
add_subdirectory(../lib2 ${CMAKE_CURRENT_BINARY_DIR}/lib2)
add_executable(test main.cpp)
target_link_libraries(test lib1 lib2)
I.e. lib2 depends on lib1 and test depends on both of them. (I know that technically static libraries don't "link", but that's just an example.)
The problem is that with the current setup, lib1 compiles twice - the first time it is within the "test" build directory, and a second time it is within "test/build_directory/lib2/build_directory". I'd like to avoid that.
I want to be able to add a dependency on lib1, lib2 or both of them (using add_subdirectory) to any project that's located elsewhere. So moving CMakeFiles isn't an option. I also want to avoid compiling any library several times.
How can I do that?
Platform: CMake v. 2.8.4 and Windows XP SP3
A top-level CMakeLists.txt file isn't an option, because I want to keep a clean top-level directory and be able to include libraries in other projects that can be located elsewhere. Because it is Windows, I can't "install package system-wide" - I don't want to lose ability to switch compiler on the fly. Utility libraries built with different compilers will use different C runtime libraries/ABI, and as a result will be incompatible.
One other solution is to add a guard at the top of the subdirectory-CMakeLists.txt:
if(TARGET targetname)
return()
endif(TARGET targetname)
Which will cause cmake to do nothing the second time the subdirectory is added (if targetname is being defined in that file, of course).
This will lead to the lib beeing build in an sort-of-arbitrary place (depending on which module added it first) in the build/ tree, but it will be built only once and linked everywhere.
In your example, you would add
if(TARGET lib1)
return()
endif(TARGET lib1)
at the top of lib1/CMakeFiles.txt
With CMake, library dependencies are transitive, so you shouldn't call add_subdirectory twice in test/CMakeFiles.txt (nor do you need to list lib1 as a dependency of test since it is already a dependency of lib2's).
So you could modify test's CMakeFiles.txt to:
cmake_minimum_required(VERSION 2.8.7) # Prefer the most current version possible
project(test)
add_subdirectory(../lib2 ${CMAKE_CURRENT_BINARY_DIR}/lib2)
add_executable(test main.cpp)
target_link_libraries(test lib2)
Also, you should probably remove the cmake_minimum_required calls from your non-project CMakeFiles.txt files (the lib ones). For further info, run:
cmake --help-policy CMP0000
This setup will still cause all libs to be recompiled if you add a similar test2 subdirectory and project which depends on lib1 and lib2. If you really don't want to have a top-level CMakeFiles.txt in projects/, then you're stuck with what you're doing, or you could use either the export or install command.
export would create a file which could be included by other projects and which imports the targets into the project which calls include.
install could install the libraries to another common subdirectory of projects/. Depending on your source directory structure, this could have the benefit of only making the intended library API headers available to dependent projects.
However, both of these options require the dependent library projects to be rebuilt (and installed) if they are modified, whereas your current setup includes all the dependent targets in your project, so any change to a source file in a dependent library will cause your test target to go out of date.
For further details about export and install, run:
cmake --help-command export
cmake --help-command install
Perhaps add a top-level CMakeLists.txt in your projects dir. Something like:
project( YourProjects )
add_subdirectory( lib1 )
add_subdirectory( lib2 )
add_subdirectory( test )
This should be sufficient and will give you a solution-file or makefile in your top-level build-dir. You should then remove the add_subdirectory( ../lib1 ... from your lib1 and lib2 projects, but instead simply link to them. CMake will know how to find lib1 and lib2 when compiling test.
I.e. in lib2:
project( lib2)
add_library(lib2 STATIC lib2.cpp)
target_link_libraries(lib2 lib1)
and in test:
project( test )
add_executable(test main.cpp)
target_link_libraries(test lib1 lib2)
Added bonus: you will get makefiles/solutionfiles for building lib2 (with dependent lib1) in the lib2 directory...