In my project I want to include some libraries. For now at least GLFW and GLEW.
I want them to be added automatically whenever I clone my repo. So my idea was to add those libraries as git-submodules and include them via my CMakeList. Both libs have a CMakeList which made me think I can easily add them with cmake.
But I don't know how to add those. I use CLion since I am not experienced with cmake or C++ in general. I tried to include them via add_subdirectory() and just treat them as normal code but then GLEW cant find header files, I tried to include them via add_library() but cmake does not use GLFWs CMakeList.
What would be the correct way of including libraries?
Related
I would like to use the range-v3 library in my project, but i don't understand how. The installation description says the following:
This library is header-only. You can get the source code from the
range-v3 repository on github. To compile with Range-v3, just #include
the individual headers you want.
Does that mean I can copy and paste the needed header files and add the filepath to my CMake file? I am a bit confused, because I never included third party library.
Note: please see hythis' answer for a better solution.
Does that mean I can copy and paste the needed header files and add the filepath to my CMake file?
Basically, yes. First git clone to <path_to_range_v3>. Then include these lines into CMakeLists.txt:
add_library(range_v3 INTERFACE IMPORTED)
set_target_properties(range_v3 PROPERTIES
INTERFACE_INCLUDE_DIRECTORIES <path_to_range_v3>/include)
target_link_libraries(your_target PUBLIC range_v3)
I'm not sure why Evg suggested what they did, I don't even think in 2019 you were forced to create your own CMake interface with ranges-v3 (see here, the file existed way before hand). Regardless, don't use Evg's solution, ranges-v3 is a good header only library, and in order for a header only library to be good it must provide CMake integration.
Header only libraries do not mean the authors do not provide CMake support, or even avoid CMake themselves. Bad authors do this, as you've probably experienced by having to ask this question in the first place.
To properly integrate with Ranges V3, use a packagemanager (though some package managers screw the process up depending on how their custom CMake files are configured) such as Conan or vcpkg and integrate with their respective CMake solutions, or add the project as a git submodule (though you could git clone it as well) then in your CMakeLists.txt:
add_subdirectory([path to submodules]/range-v3)
...
target_link_libraries(my_target [SCOPE] range-v3::range-v3)
It can be hard to figure out actual targets for libraries if the authors don't spell out how to use their projects in a CMake project, and I don't blame any one making an SO post about it, it's a pain.
Generally if the project has a CMakeLists.txt file, it probably has static-library/sub_directory cmake integration, but some libraries only have install targets, thus are unusable when baked into your source code with out editing their CMakeLists.txt
To check if this is the case, or if you can actually use the targets, if you can't find any CMake documentation about how to use the library (which I couldn't) do the following:
Look inside the CMakeLists.txt file
Find a project alias usually in the form of project_name::project_name. This is how I found range-v3's project alias.
If you can't find alias (via searching for ::), find the actual target name for the library (and try to use this directly), sometimes this isn't exported though (hidden in a sub directory from the top cmake file). OpenCV doesn't use :: for example, and instead each component target is marked with opencv_[component name] but still exported.
If the project has not been configured to be properly used as a submodule and is otherwise meant to be used as a static library, submit an issue or PR to the given repository, this is a bug.
I would like to be able to dynamically compile a library that will be used by my project before compiling my project.
I am setting up a Vulkan project in C++ (with Clion) and would like it to be multi-platforms, I am using GLFW3.3 to make that happen.
Instead of building my library for each platform and putting the libs and .h in a folder that will be linked through the CMakeLists.txt, I would like to be able to CMAKE+make the library, then put the lib and .h where they need to be and then start compiling my program that will be using those.
GLFW has a working CMakeLists.txt (I manage to make it manually through the console) but I don't know how to tell CMAKE to make it etc.
I am used to using CMake to define path to libs and includes but my last project what also multi-platforms and I didn't like the way I handled the library (build manually etc).
So I am looking for a way in CMake to do everything at once even if it will take time to do so but I have no idea how that works.
Take a look at how Glitter does it:
option(GLFW_BUILD_DOCS OFF)
option(GLFW_BUILD_EXAMPLES OFF)
option(GLFW_BUILD_TESTS OFF)
add_subdirectory(Glitter/Vendor/glfw)
target_link_libraries(${PROJECT_NAME} ... glfw)
They just include the CMakeLists.txt file that GLFW provides and depend on it for the main target.
I'm creating a very small project that depends on the following library: https://github.com/CopernicaMarketingSoftware/AMQP-CPP
I'm doing what i always do with third-party libraries: i add their git repo as a submodule, and build them along with my code:
option(COOL_LIBRARY_OPTION ON)
add_subdirectory(deps/cool-library)
include_directories(deps/cool-library/include)
target_link_libraries(${PROJECT_NAME} coollib)
This has worked perfectly for libraries like Bullet, GLFW and others. However, this AMQP library does quite an ugly hack. Their include directory is called include, but in their CMake install() command, they rename it to amqpcpp. And their main header, deps/cool-library/amqpcpp.h, is referencing all other headers using that "fake" directory.
What happens is: when CMake tries to compile my sources which depend on deps/cool-library/amqpcpp.h, it fails because it's not finding deps/cool-library/amqpcpp/*.h, only deps/cool-library/include.
Does anyone have any idea how i can fix this without having to bundle the library into my codebase?
This is not how CMake is supposed to work.
CMake usually builds an entire distributive package of a library once and then installs it to some prefix path. It is then accessible for every other build process on the system by saying "find_package()". This command finds the installed distibution, and all the libs, includes etc. automagically. Whatever weird stuff library implementers did, the resulting distros are more or less alike.
So, in this case you do a lot of unnecessary work by adding includes manually. As you see it can also be unreliable.
What you can do is:
to still have all the dependencies source distributions in submodules (usually people don't bother doing this though)
build and install each dependency package into another (.gitignored) folder within the project or outside by using their own CMakeLists.txt. Let's say with a custom build step in your CMakeLists.txt
use "find_package()" in your CMakeLists.txt when build your application
Two small addition to Drop's answer: If the library set up their install routines correctly, you can use find_package directly on the library's binary tree, skipping the install step. This is mostly useful when you make changes to both the library and the dependent project, as you don't have to run the INSTALL target everytime to make library changes available downstream.
Also, check out the ExternalProject module of CMake which is very convenient for having external dependencies being built automatically as part of your project. The general idea is that you still pull in the library's source as a submodule, but instead of using add_subdirectory to pull the source into your project, you use ExternalProject_Add to build it on its own and then just link against it from your project.
So basically I have the following setup:
A small test library called mylib with an according CMake file. The CMake file creates all the necessary information so that another project (which is going to be my binary) can use find_package to add the library. The library also has a install target.
A small binary called mybin again wih according CMake file which is depended on the mylib project. Using find_package I can add mylib either by specifying the location of the according myLibConfig.cmake (and myLibTargets.cmake etc.) files or by executing the install target of mylib and then letting CMake find the library itself.
Using CMake and XCode everything works like a charm. First, I configure and build the library. Second, I configure my binary project, specify the location of the library and then build it without any problems.
Now I want to do the same using CLion. My problem now is that CLion puts all the generated CMake file (which usually are placed in the build folder) in some cryptic location which can't be changed in the IDE. Now, when I want to build the mybin project I have to specify this cryptic location which seems kinda odd to me (especially because you have to find out first where CLion actually places those files).
So my question is: Is there a more convenient way to handle the described configuration? I guess this is more or less the standard use case which makes me wonder if I'm missing out on something. Being able to specify where CLion should put the generated CMake files would solve my problem I guess.
I know that i can install the library (using the install target) and then let CMake find it. The problem here is that CLion (to my understanding) doesn't support install targets and therefore I have to use (in my case) XCode to build and install the library first.
I was misunderstsanding the intention of find_package(as Tsyvarev pointed out). By using the solution proposed in this question I managed to add an install target to CLion which now allows me to conveniently build "mylib" and use it in the "mybin" project without having to configure anything manually.
I'm developing a lib and now trying to make it usable through cmake find_package keyword.
Using the config mode works fine.
I've put the CPackConfig.cmake generated by cmake inside the installation folder of my lib by naming it log++Config.cmake and it can be found in my project. Fine.
But this method is not satisfying. I need to define my own variables such as lib dependencies needed to link and some custom macros, and didn't found any way to embed this inside the CPackConfig.cmake.
So now I'm trying to use the module mode of find_package. My concern is that I can't find any way to have cmake use my Findlog++.cmake without putting it inside cmake installation folders (which is awfully ugly).
I've found some posts telling to just put this file inside my project root but it's almost as ugly as modifying cmake itself.
Is there a way to have my Findlog++.cmake file somewhere inside my lib folder and have cmake finding it without setting the CMAKE_MODULE_PATH variable?
You seem to be confused between CPack and 'config file packages'. First, understand that they are separate and different. Then read
http://www.cmake.org/cmake/help/v3.0/manual/cmake-packages.7.html#creating-packages
http://www.cmake.org/cmake/help/v3.0/manual/cmake-buildsystem.7.html
to learn about usage requirements and inclusion of macros etc.