I am trying to integrate spdlog, a header only logging library into a C++ project but I am having trouble getting CMake to recognise the include paths properly. I am using the latest CLion with CMake 3.10.2 on Ubuntu 18.04.
My project structure looks like this:
Project Dir
|- libs
| |- spdlog #this is the include directory taken straight from GitHub
|
|- src
| |-...
|- CMakeLists.txt
In the CMakeLists.txt file I define the include directory:
include_directories("libs/")
Now when I attempt to write #include <spdlog/spdlog.h> in a header file located in src/ CLion complains that it cannot find spdlog.h even though I have checked and the file is definitely in the spdlog folder. Using quotation marks instead of angled brackets in the include statement does not fix the problem however using the path relative to the file (e.g. ../libs/spdlog/spdlog.h) works as it should. What is more confusing to me is that in the source file corresponding to the header I can include the file no problem.
I haven't been able to find anything like this issue anywhere and I'm struggling to understand what is causing CMake or CLion to behave like this.
EDIT: As per Matthieu Brucher's suggestion I have tried using fully qualified paths to the include folder but it still does not work. The problem seems to be that folders seem to not be recognised in headers, as they work in source files.
EDIT2: Here is the entire CMakeLists.txt I am using. It is nested into a different directory than the top level CMakeLists.txt for the entire project as this was the only solution I have found online to get something akin to VS's multiple projects in a solution in CLion. However since all paths are relative I don't think this would be a problem. I also know that spdlog is a C++11 library but I will need some C++14 features elsewhere in the near future.
cmake_minimum_required(VERSION 3.10 FATAL_ERROR)
project(TokenEngine VERSION 0.0.1 LANGUAGES CXX)
set(CMAKE_CXX_STANDARD 14)
set(SOURCE_FILES src/Application.cpp src/Application.hpp src/EntryPoint.hpp src/Logger.cpp src/Logger.hpp)
include_directories("${CMAKE_CURRENT_SOURCE_DIR}/libs/")
add_library(TokenEngine SHARED ${SOURCE_FILES})
#Expose the public API of the engine to any project that might use it
target_include_directories(TokenEngine PUBLIC include)
EDIT3: When I attempted to recreate the error to show the full message given somehow the it was gone, being replaced by a different one totally unrelated to CMake...
You may want to use fully qualified paths:
include_directories(${CMAKE_SOURCE_DIR}/libs/)
You also have to add the include folder to the include paths to be able to include via #include <spdlog/spdlog.h>. This should look like
include_directories(${CMAKE_SOURCE_DIR}/libs)
But I prefer using
target_include_directories(yourTarget PUBLIC ${CMAKE_SOURCE_DIR}/libs)
where yourTarget is the target where you want to use spdlog. Like that you will have the include directories also available if you are going to link your yourTarget to something else. If you need spdlog just in yourTargets cpp files you can change the PUBLIC to PRIVATE. See cmake doc.
Related
I want to use the following library
https://github.com/gmeuli/caterpillar
It's documentation says that it's a header-only library, and that I should "directly integrate it into my source files with #include <caterpillar/caterpillar.h>." It also depends on a few other libraries, one of which I need to use directly as well.
So far I have done the following:
create cmake project to make an 'executable' (with the vscode extension)
created a 'lib' folder, inside which I did
git clone https://github.com/gmeuli/caterpillar
Then, I did include_directories(lib) in my cmake file.
But #include <caterpillar/caterpillar.h> doesn't quite work in my singular main.cpp file.
I played around with various CMake functions, and it either gave the error "No such file or directory" regarding caterpillar/caterpillar.h itself, or it gave "cannot open source file... dependent of caterpillar/caterpillar.h" depending on how I messed with the cmake file.
For reference:
cat ~/project/main.cpp
#include <caterpillar/caterpillar.hpp>
#include <lorina/lorina.hpp> //how do I include this ? it's in the lib folder of caterpillar itself, or do I need to have a copy of it in my lib folder too
int main()
{
// stuff in lorina:: namespace
// stuff in caterpillar:: namespace
return 0;
}
cat ~/project/CMakeLists.txt
include_directories(lib)
//... rest is stuff like CXX standard, etc etc
tree ~/project
main.cpp
lib/
caterpillar/
build/
cmake generated stuff
CMakeLists.txt
Firstly, modern cmake recommends target_include_directories() instead of old include_directories() for better scope management.
Actually <caterpillar/caterpillar.hpp> is not in $PROJECT_SOURCE_DIR/lib directory. That's why your code not works.
CMakeLists example:
cmake_minimum_required(VERSION 3.22)
project(myproject)
set(CMAKE_CXX_STANDARD 17)
add_executable(my_project main.cpp)
target_include_directories(my_project PRIVATE ${PROJECT_SOURCE_DIR}/lib/caterpillar/include)
# project_src_dir/lib/catepillar/include/ is the directory where you find the headers like <catepillar/catepillar.hpp>
target_include_directories(my_project PRIVATE ${PROJECT_SOURCE_DIR}/lib/caterpillar/lib/lorina)
caterpillar's document describes how to include their headers in a traditional style, assuming the readers could understand this and decide where to put the headers themselves. (which means you don't need the whole git repo but only the "include" dir.)
For this specific problem, the library has provided a detailed CMakeLists.txt for users to include:
cmake_minimum_required(VERSION 3.22)
project(my_project)
set(CMAKE_CXX_STANDARD 17)
add_subdirectory(lib/caterpillar)
# this works because "project_src_dir/lib/catepillar/CMakeLists.txt" exists.
add_executable(my_project main.cpp)
target_link_libraries(my_project PRIVATE caterpillar)
# you need to tell cmake to add all catepillar settings into your project
This is similar to Including directories in Clion, but after following the accepted answer there I made no progress.
I'm trying to edit a large OSS project in CLion. It does not use CMake, so CLion has generated a CMakeLists.txt file. When I open a source file, it is unable to resolve includes that use sub directories:
The file this screenshot is from is in the same "opto" subdirectory it is importing from. If I change the imports to not include "opto" it works fine, but I can't do that, since this is a major project and I'm just wanting to write a small patch:
$ find . -type f | wc -l
10532
I've added the file I'm importing directly to add_executable as suggested in the other answer:
# CMakeLists.txt
add_executable(hotspot
[lots of other files]
src/share/vm/opto/compile.hpp
)
And I've added the opto directory to include_directories as outlined in the second answer to the other question:
# CMakeLists.txt
include_directories(
src
src/share/vm/opto)
Neither is helping CLion resolve imports via the opto subdirectory.
What am I missing?
Using include_directories() must do, but you have to mention each sub_directory separately. Below i have included two directories in the same way where one of it is sub_directory.
The Header files have successfully been detected by CLion.
Whenever I wanted to include a directory that was located outside of my project with Clion I would use the -I somedir flag. This time however, what I want to do is to have a hierarchy like this:
/project
CMakeLists.txt
/src
/Graph
Graph.h
Graph.cpp
/Dijkstra
Dijkstra.h
Dijstra.cpp
I want my code in a /src directory. And not only that, but also, for example, inside the file Dijkstra.h I want to include the Graph.h like this: #include "Graph/Graph.h and not like this: #include "../Graph/Graph.h.
If I only add an -I src flag, then if I am inside the Dijkstra.h file and I wanted to include Graph.h, I would have to write #include "../Graph/Graph.h, which is not what I want.
So I tried to also add INCLUDE_DIRECTORIES(src). That fixed the problem above, however when tried to compiled, I got a linker error undefined reference to....
So I tried adding the files one by one like this:
set(SOURCE_FILES
src/Dijkstra/Dijkstra.h
src/Dijkstra/Dijkstra.cpp
src/Graph/Graph.h
src/Graph/Graph.cpp)
add_executable(someprojectname ${SOURCE_FILES})
and that brought back the previous problem, where I had to include the files like this: #include "../Graph/Graph.h".
How can I do this properly to get the behavior I want ?
Command INCLUDE_DIRECTORIES doesn't add any source file for compile!
Instead, this command defines directories for search header files.
You need to list all source files in add_executable() call in any case:
include_directories(src)
set(SOURCE_FILES
src/Dijkstra/Dijkstra.cpp
src/Graph/Graph.cpp)
add_executable(someprojectname ${SOURCE_FILES})
UPDATE: #Tsyvarev's answer is correct. I've edited this answer to remove the incorrect part and keep the comments relating to target_include_directories(), but it should be viewed as additional to Tsyvarev's answer.
INCLUDE_DIRECTORIES(src) will make the src directory get added as a search path to all targets defined from that point on. It does not add sources to any targets. The search path will be relative to the current source directory and CMake will adjust it as appropriate when descending into subdirectories via add_subdirectory(). While this is fine if that's what you want, as the project gets bigger and more complicated, you may find you would prefer to apply the include path settings to just some targets. For that, use target_include_directories() instead:
target_include_directories(someprojectname "${CMAKE_CURRENT_SOURCE_DIR}/src")
This will have the same effect, but it restricts the use of the added include path to just the someprojectname target. If you later define some other target which doesn't need the include path, it won't be added. This can help prevent situations like unexpected files being picked up if you have deep directory hierarchies and you re-use directory names in different places, for example).
The target_include_directories() command has additional benefits when applied to library targets because CMake has the ability to carry the include path through to anything you link against that library too. Doesn't sound like much, but for large projects which define and link many libraries, it can be a huge help. There are other target-specific commands which have similar benefits too. This article may give you a bit of a feel for what is possible (disclaimer: I wrote the article). It is more focused on target_sources(), but the discussion around carrying dependencies through to other targets may be useful.
I have been struggling with this for quite a while, and my adventures with cmake have only resulted in hackish solutions that I am pretty sure are not correct.
I created a library that consists of several files, as follows:
-libfolder
-codepart1folder
-CMakeLists.txt
-codepart1.cpp
-codepart1.hpp
-codepart2folder
-codepart3folder
-lib.cpp
-lib.hpp
-CMakeLists.txt
I wrote a CMakeLists file to compile the library (after some experimentation), and I can generate a lib.a file. Now I would like to include this code as a library in other projects, and access it through the interface in lib.hpp. What is the best way to do this, in terms of directory structure, and what I need to put into CMakeLists.txt in my root project?
My current attempt has been to add -libfolder as a subfolder to my current project, and add the commands:
include_directories(${PROJECT_SOURCE_DIR}/libfolder)
link_directories(${PROJECT_BINARY_DIR}/libfolder)
add_subdirectory(libfolder)
target_link_libraries(project lib)
When I run make, the library compiles fine, but when project.cpp compiles, it complains that it cannot find codepart1.hpp (which is included in lib.hpp, included from project.cpp).
I suspect that this is the wrong way about doing this, but I cannot wade through the CMake documentation and find a good tutorial on setting up projects like this. Please help, CMake gurus!
The clean way to import one CMake project into another is via the find_package command. The package declaration is done by using the export command. An advantage of using find_package is that it eliminates the need to hard-code paths to the package's files.
Regarding the missing hpp file, you didn't include codepart1folder, so it's not on the include path.
Ok, so after consulting a coworker of mine who is a CMake guru, it seems CMake does not have support for what I am trying to do, leaving one with 3 options:
Add all of the dependencies to the parent projects CMakeLists.txt - not very clean, but it will get the thing to work. You'll have to do this for every project you add the code to, and go back and fix things if your library changes.
clean up your library headers. This is done through some compiler hackery. The idea is to forward-declare every class, and use only pointers or boost::shared_ptr, and then include the dependencies only in the cpp file. That way you can build the cpp file using all the findpackage stuff, and you get the bonus of being able to use the lib by only including the header and linking to the library.
Look into build systems. Having portable code and fast code compilation with complex dependencies is not a solved problem! From my investigations it turned out to be quite complicated. I ended up adopting my coworkers build system which he created himself in cmake, using things he picked up from Google.
Looking at your post you don't seem to add 'codepart1folder' to the includes anywhere. How are you including codepart1.hpp as:
#include <codepart1.hpp>
#include "codepart1folder/codepart1.hpp"
I don't think there is a standard accepted way to structure cmake projects. I've looked at a bunch of cmake repos and they tend to have differences. Personally I do the following:
-project
CMakeLists.txt
-build
-cmake
OptionalCmakeModule.cmake
-src
-Main
Main.cpp
Main.hpp
-DataStructs
SomeTree.hpp
SomeObject.hpp
-Debug
Debug.hpp
-UI
Window.hpp
Window.cpp
Basically that dumps all the source code into 1 directory, then you perform an out of source build with: 'mkdir build && cd build && cmake .. && make' in the projects root folder.
If you have separate libs as part of your project, then you might want a separate libs directory with another subfolder for your specific lib.
I have some of my repos on: https://github.com/dcbishop/ if you want to look at the CMakeLists.txt files.
The main problems with my project structure are that I use the FILE_GLOB which is apparently the 'wrong' way to do things (if you add files after running 'cmake ..' then they won't be picked up hen you do a 'make'). I haven't figured out what the 'right' way to do it is (from what I can see it involves keeping a separate list of files) I also only use 1 CMakeLists.txt file.
Some projects also choose to separate their cpp and hpp files into separate directories. So you would have an include and src folders (at least for the hpp files that are intended to be used externally). I think that would mainly be for projects that are mainly large libraries. Would also make installing header files much easier.
You are probably missing
include_directories(${PROJECT_SOURCE_DIR}/libfolder/codepart1folder)
In such a case you might want to set( CMAKE_INCLUDE_CURRENT_DIR on) to add all folders to the include directory path variable.
Check cmake's output on the command line whether the correct include folders are set or not. Additionally you can always use message() as "print debugging" for cmake variables.
In case of include directories however you need to read the directory property to see what is actually in the include directories.
get_property(inc_dirs DIRECTORY PROPERTY INCLUDE_DIRECTORIES)
message("inc_dirs = ${inc_dirs}")
I hope this helps you figuring out what is missing.
Edit
I just saw your comment about added codepart1folder in the libfolder. It is only available in the libfolder's include_directory path and not propagated to the root folder.
Since the include codepart1.hpp is present in the lib.hpp however you need to have it also available in the project path otherwise you will get missing declaration errors when you build your project.
tl;dr the questions are at the bottom.
I am a developer trying something new - my last poison is c++. As I am spending half of my time on my linux laptop and the other half on Win XP PC, I tried to find a way to create basic, barebone project, using good c++ practices (well, I don't know them from experience, I just read about them). Right now my project almost works while using cmake . && make on linux (it works when header and source files are in the same folder, fails when I separate them to include / src folders). I am using nuwen's distribution of mingw on windows (and I know that the toolchain is working, it compiles projects from within Eclipse without any problems).
My project directory looks like this:
engine
|
|- main
|
|- include
|
|- App.h
|- CMakeLists.txt (2)
|- src
|
|- main.cc
|- App.cc
|- CMakeLists.txt (3)
|- CMakLists.txt (1)
The contents of the files are very simple (I will remove the include guards, etc for clarity)
App.h:
class App {
public:
App();
int onExecute();
};
App.cc:
#include <iostream>
#include "App.h"
App::App() {
}
int App::onExecute() {
std::cout << "inside app.." << '\n';
return 0;
}
main.cc:
#include <iostream>
#include "App.h"
using namespace std;
int main(int argc, char* argv[]) {
App a;
a.onExecute();
std::cout << "inside main.." << '\n';
}
CMakeLists.txt (1) - the main one:
cmake_minimum_required (VERSION 2.6)
set (CMAKE_CXX_COMPILER "g++")
project (gameengine)
add_definitions ( "-Wall -ansi -pedantic")
add_subdirectory (${CMAKE_SOURCE_DIR}/main/include)
add_subdirectory (${CMAKE_SOURCE_DIR}/main/src)
add_executable (engine ${CMAKE_SOURCE_DIR}/main/src/main.cc)
target_link_libraries (engine Application)
CMakeLists.txt (2) - inside the include directory
add_library (Application App)
set_target_properties (Application PROPERTIES LINKER_LANGUAGE CXX)
CMakeLists.txt (3) - inside the src directory
include_directories (../include)
And this is as far as I got - with some changes (i.e. moving App.cc to the include directory) the whole thing compiles and runs fine on linux - but I can't get the mingw generator to work on Win XP. I hand tuned the CMAKE_MAKE_PROGRAM in the file CMakeCache.txt to point to the proper make.exe (I know that this should be defined as a system variable but as I am working on many different PC's, I don't want to leave junk after me).
My questions are:
1) what are the guidelines for writing multiplatform CMakeLists.txt file (which will work independly of the os and the location of the project files), which preferably will allow me to easy swich my project configuration from one os the other one?
2) how can I address the error of not finding the header file (make gives: (...)\engine\main\src\main.cc:2:17: fatal error: App.h: No such file or directory) ?
Thank you for your time and help.
1) what are the guidelines for writing multiplatform CMakeLists.txt file (which will work independly of the os and the location of the project files), which preferably will allow me to easy swich my project configuration from one os the other one?
Well, I'm certainly no expert, but I can share my 10-month experience with a cross-platform cmake-based project.
Right off the bat I think you really should be using out of source builds. This means that you don't run cmake in the same directory where your code is; instead, you create a new folder, e.g. engine/build and run cmake ../main from there. This way you don't clobber your source files with cmake stuff, such as CMakeCache.txt etc. There are even some macros you can use to forbid your users from doing in-source builds.
I also find it useful to create a set of macro files to help set compiler options for different platforms. Here at work we have macros such as ADD_GCC_FLAG or ADD_MSVC_FLAG which check the current compiler and add flags accordingly.
I think it is good practice to have a single .cmake file which concentrates all your project configurations in one place. At work all our CMakeLists.txt start with include( ../cmake/configs.cmake ). This file sets all sorts of options, such as standard include directories, default compiler flags etc.
To assuage your problem with include directories, I suggest you use absolute rather than relative paths in your source files. Define a standard include directory, for instance engine/main/include and always #include files relative to that path. In your example, if you wanted to include engine/main/include/somefolder/header.h, you'd write #include <somefolder/header.h> (using <> instead of quotes tells the C++ preprocessor to skip the current directory when looking for the file).
2) how can I address the error of not finding the header file (make gives: (...)\engine\main\src\main.cc:2:17: fatal error: App.h: No such file or directory) ?
There are a number of issues with your cmake layout, but the reason you were getting that error is because you need to call include_directories in CMakeLists.txt (1) as well.
Besides that, your other CMakeLists.txt files have problems too. In CMakeLists.txt (2), the arguments to add_library are wrong; it should be ../src/App.cc, otherwise you're just adding an empty library. And you don't need that set_target_properties either, at least not if you got the add_library arguments right. You also need a include_directory call in that same CMakeLists.txt that's adding the library; putting it in (3) doesn't really do anything.
Actually, you don't need a CMakeLists.txt file in the include directory, since there's nothing to build there. It's better to put the add_library call in CMakeLists.txt (3), right after calling include_directories.
I hope this clears some of your doubts.
This is probably not the answer you expect but since you didn't stated whether you'd like alternative solutions, I will suggest it anyway:
For multi-platform projects I would recommend SConstruct which is really a great and flexible tool. I don't know CMake well so I can really provide a detailed comparison.
However, here are the reasons why I love this tool:
It's Python. So you can do almost anything you want regarding customization and/or special needs
It's really easy to learn and for simple projects, it takes only a few lines of code to get started.
It depends solely on Python so on Linux its very often already installed and on Windows it take 5 minutes to download and install.
It has a very good automatic dependency tree generation and parallel compilation support.