As in Google C++ Style Guide is mentioned all of a project's header files should be listed as descendants of the project's source directory without use of UNIX directory shortcuts . (the current directory) or .. (the parent directory). How can I do that in my project that is shortly described below.
My project directory hierarchy is like this:
GraphicsEngine
header_files.h
source_files.cc
CMakeLists.txt (1)
Light
CMakeLists.txt (2)
header_files.h
source_files.cc
Camera
CMakeLists.txt (3)
header_files.h
source_files.cc
Core
CMakeLists.txt (4)
header_files.h
source_files.cc
These are contents of CMakeLists.txt files:
CMakeLists.txt (1)
add_library(GraphicsEngineLib source_files.cc)
target_link_libraries(GraphicsEngineLib LightLib CameraLib CoreLib)
add_subdirectory(Light)
add_subdirectory(Camera)
add_subdirectory(Core)
CMakeLists.txt (2)
add_library(LightLib source_files.cc)
CMakeLists.txt (3)
add_library(CameraLib source_files.cc)
CMakeLists.txt (4)
add_library(CoreLib source_files.cc)
Now when for example I want to include header files from Camera folder in to files in Core folder, I have to use ../Camera/header_file.h but I want to use GraphicsEngine/Camera/header_file.h. How can I do this?
What I have done in the past is to set this in the top level CMakeLists.txt (which should be in your GraphicsEngine directory):
SET(PROJECT_ROOT "${CMAKE_CURRENT_SOURCE_DIR}/..")
INCLUDE_DIRECTORIES(
${PROJECT_ROOT}
)
where according to this, CMAKE_CURRENT_SOURCE_DIR is
this is the directory where the currently processed CMakeLists.txt is located in
Note that by defining Project_Root in this way, your GraphicsEngine project can also #include headers from sister projects to GraphicsEngine.
Hope this helps.
Related
In a Meson project, how can I compile files (i.e. not just headers) located in an directory which is not in my project tree?
E.g.:
MyProj/
src/
meson.build
ExternalCode/
src/
file1.h
file1.cpp
include_directories is just for headers...
If I use ".." in the files path, I get this error:
meson.build:10:0: ERROR: Subdir contains ..
If you want to build ExternalCode as a part of your project, then I recommend fetch somehow this directory inside your project, e.g. using symbolic link and place meson.build file alongside. So, your project layout will look as:
MyProj/
meson.build
src/
meson.build
external/
ExternalCode -> link to ...
meson.build
Then, make aware meson of all sub-directories in the project placing this in top level meson.build file:
subdir('src')
subdir('external')
yes but the external file must be picked up in the following way:
e.g.
source = files(file1.cpp)
put in meson.build inside
ExternalCode/src
folder
I'm trying to set up cmake for a project I'm working on, but I have a problem which I can't resolve currently. My project has the following folder structure:
MotorEngine (root dir)
| CMakeLists.txt
| ThirdParty
|-| SDL2
|-|-| include (contains all header files for SDL2)
|-|-| lib
|-|-|-| x64
|-|-|-|-| SDL2.lib (the library file I need to link with)
| Source
|-| CMakeLists.txt
|-| main.cpp
The root CMakeLists.txt file:
cmake_minimum_required(VERSION 2.6)
project(MotorEngine)
# Set an output directory for our binaries
set(BIN_DIR ${CMAKE_CURRENT_SOURCE_DIR}/Binaries)
set(CMAKE_RUNTIME_OUTPUT_DIRECTORY ${CMAKE_CURRENT_SOURCE_DIR}/Binaries)
set(THIRDPARTY_PATH ${CMAKE_CURRENT_SOURCE_DIR}/ThirdParty)
# Include SDL2
include_directories(${THIRDPARTY_PATH}/SDL2/include)
# Add the engine + third party subdirectory
add_subdirectory(Source)
The Source's CMakeLists.txt:
project(MotorEngine)
add_executable(MotorEngine main.cpp)
target_link_libraries(MotorEngine ${THIRDPARTY_PATH}/SDL2/lib/x64/SDL2.lib)
Now, I want to achieve the following, in the main.cpp I want to write
#include "SDL2/include/SDL2.h"
But currently I have to write
#include "SDL2.h"
Since there will be files with the same name later on, I need to distinguish them in their folders. So the easiest would be to add the "ThirdParty" folder as a root so I can use #include relative to that then, but doing
include_directories(${THIRDPARTY_PATH})
does not work. Any ideas? Thank you!
With help of k.v. I was able to sort this out. I needed to add the following in the CMakeLists.txt in the Source directory:
target_include_directories(MotorEngine PUBLIC ${THIRDPARTY_PATH})
I have a CMake project that looks like this:
project/
CMakeLists.txt
subprojectA/
CMakeLists.txt
include/
headerA.hpp
src/
libraryA.cpp
subprojectB/
CMakeLists.txt
src/
mainB.cpp
The "library" subproject, A, is compiled as a static library, becoming libsubprojectA.a. The "main" project, B, is compiled as a binary and depends on the library. mainB.cpp includes a reference to headerA.hpp.
Here is subprojectA/CMakeLists.txt:
project(SubProjectA)
include_directories(include)
add_library(subprojectA STATIC src/libraryA.cpp)
set(${PROJECT_NAME}_INCLUDE_DIRS
${PROJECT_SOURCE_DIR}/include
CACHE INTERNAL "${PROJECT_NAME}: Include Directories" FORCE)
And here is subprojectB/CMakeLists.txt:
project(SubProjectB)
include_directories(${SubProjectA_INCLUDE_DIRS})
add_executable(mainBinary src/mainB.cpp)
target_link_libraries(mainBinary subprojectA)
The main Project CMakeLists.txt looks like:
project(Project)
add_subdirectory(subprojectB)
add_subdirectory(subprojectA)
Note that subprojectB, the main project, is listed before subprojectA.
Here's the problem. When I first run "cmake" on this project, ${SubProjectA_INCLUDE_DIRS} is not set within SubProjectB.
What I think is happening is that the CMakeLists for SubProjectB loads first, when ${SubProjectA_INCLUDE_DIRS} has not yet been set. It sets its own include path to an empty string as a result. However, even though libsubprojectA.a gets built successfully before mainBinary, the include path was already set empty beforehand. As a result, I get this error when trying to make mainBinary:
subprojectB/src/mainB.cpp:1:23: fatal error: headerA.hpp: No such file or directory
#include "headerA.hpp"
^
It's a workaround to put subprojectA before subprojectB in the main Project CMakeLists in the declarative world of CMake. What I really want is to know the proper way to indicate to CMake that the include_directories(${SubProjectA_INCLUDE_DIRS}) line depends on the definitions that exist inside SubProjectA's CMakeLists. Is there a better way to do this?
If you want to express that include directory subprojectA/include is an interface of the library subprojectA, attach this property to the target with target_include_directories command:
subprojectA/CMakeLists.txt:
project(SubProjectA)
add_library(subprojectA STATIC src/libraryA.cpp)
# PUBLIC adds both:
# 1) include directories for compile library and
# 2) include directories for library's interface
target_include_directories(subprojectA PUBLIC include)
So any executable(or other library) which linked with subprojectA will have this include directory automatically:
subprojectB/CMakeLists.txt:
project(SubProjectB)
add_executable(mainBinary src/mainB.cpp)
target_link_libraries(mainBinary subprojectA)
Of course, for use last command properly you need to process directory with library before one with executable:
CMakeLists.txt:
project(Project)
add_subdirectory(subprojectA)
add_subdirectory(subprojectB)
I have been given some C++ which I want to use in my project. This code comes with its own CMakeLists.txt file. To keep things neat, I want to make a new directory foo in my main project directory, and put this code and the CMakeLists.txt file in that directory. What I now want to know, is how do I edit the CMakeLists.txt file of my own project, to include all the source files from this other project?
Normally, I use file(glob SOURCES *.cpp) to create a list of all source files. Then, I would create the executable by using add_executable(${PROJECT_NAME} ${SOURCES}). However, how do I tell SOURCES to also include all the source files in the foo directory?
Now, if I use add_subdirectory(foo) in my main CMakeLists.txt file, then I believe this will search directory foo for a CMakeLists.txt file, and effectively add this to the main CMakeLists.txt file in my project. Is this correct? How can I extend this to including all the source files in this directory?
Thanks!
Till date I still do not really understand what the 'best practice' is for doing this for a CMake project with many subdirectories.
Say I have a project hierarchy as such and each subdirectory has source files in it...
--CMake Project Source dir
|-- SubD1
|-- SubSubD1
|-- SubD2
What I would usually do is to do add_subdirectory(SubD1) and respectively for D2 in the CMakeLists.txt of the root directory and recursively for the subdirectory in the CMakeLists.txt of the SubD1 directory, while declaring variables in each subdirectory and making them visible in the root directory with PARENT_SCOPE.
That means if a file Source2.cpp exists in `SubSubD1', I'd simply do
set(SUBSUBD1_SOURCES Source2.cpp PARENT_SCOPE)
and expect to be able to use SUBSUBD1_SOURCE in my SubD1 directory.
Subsequently, say Source.cpp exists in SubD1, I would do
set(SUBD1_SOURCES ${SUBSUBD1_SOURCES} Source.cpp PARENT_SCOPE)
so that all sources would be visible in root dir.
The problem is of course that the file paths aren't kept when the variables arrive at the root directory. What I'm currently doing is for all source files that I set, I include a ${CMAKE_CURRENT_LIST_DIR}, making it
set(SUBSUBD1_SOURCES ${CMAKE_CURRENT_LIST_DIR}/Source2.cpp PARENT_SCOPE)
and
set(SUBD1_SOURCES ${SUBSUBD1_SOURCES} ${CMAKE_CURRENT_LIST_DIR}/Source.cpp PARENT_SCOPE)
In this case, I could then say, do add_executable(myProg SUBSUBD1_SOURCES) in the root directory of my CMake project.
Are there any better ways of doing this then having to always include a CMake variable in front of all source files?
There is a fourth way if you're using newer versions of CMake.
Take a look at target_sources() command of CMake.
It seems like you are declaring your target in your CMakeLists.txt
add_executable(my_target "subd1/CMakeLists.txt" "subd2/CMakeLists.txt")
add_subdirectory(subd1)
add_subdirectory(subd2)
Instead of propagating your Source files up to the root you can depend on the target you have defined in the root CMakeLists.txt. That means subd1/CMakeLists.txt may look like:
target_sources(my_target PRIVATE "subd1/Source.cpp" "subd1/Source2.cpp")
[EDIT]
As stated in the comments you must give the relative path of the source-files to target_sources(). I use target_sources() because I do not want the explicit source file listing to pollute the targets CMakeLists.txt. Another use case is that target_sources() can be invoked with the PUBLIC or INTERFACE keyword to propagate source files to depending targets. Well I never used target_sources() that way.
[/EDIT]
If you're using IDEs like Visual Studio that support folders you make want to also declare a source_group() in the CMakeLists.txt that contains your target. So the root CMakeLists.txt may look like:
add_executable(my_target "subd1/CMakeLists.txt" "subd2/CMakeLists.txt")
add_subdirectory(subd1)
add_subdirectory(subd2)
...
source_group(subd1 REGULAR_EXPRESSION "subd1/*")
source_group(subd2 REGULAR_EXPRESSION "subd2/*")
I'm using this approach because it leads to much cleaner CMakeLists.txt files, its lesser work and I think the introduction of not needed variables only raises the complexity of your CMakeLists.txt files.
CMakeLists.txt as target sources
I currently use the CMakeLists.txt of the sub folders as source files of the target because otherwise CMake will complain that the add_executable command has no source files given.
There are 3 ways I have used before. I normally prefer the 1st way, but have already used all 3 depending on the use case:
1. You directly name the sources in your root CMakeLists.txt file
set(
SUBD1_SOURCES
"SubD1/SubSubD1/Source2.cpp"
"SubD1/Source.cpp"
)
set(
SUBD2_SOURCES
"SubD2/Source3.cpp"
)
add_executable(myProg ${SUBD1_SOURCES} ${SUBD2_SOURCES})
2. You use OBJECT intermediate libraries to collect/group your sources
SubD1/SubSubD1/CMakeLists.txt:
add_library(SubSubD1Objs OBJECT Source2.cpp)
SubD1/CMakeLists.txt:
add_subdirectory(SubSubD1)
add_library(SubD1Objs OBJECT Source.cpp)
CMakeLists.txt:
add_executable(myProg $<TARGET_OBJECTS:SubSubD1Objs> $<TARGET_OBJECTS:SubD1Objs>)
3. You write your own function() to collect the data (and do the prefixing)
CMakeLists.txt:
function(my_collect_sources)
foreach(_source IN ITEMS ${ARGN})
if (IS_ABSOLUTE "${_source}")
set(source_abs "${_source}")
else()
get_filename_component(_source_abs "${_source}" ABSOLUTE)
endif()
set_property(GLOBAL APPEND PROPERTY GlobalSourceList "${_source_abs}")
endforeach()
endfunction(my_collect_sources)
add_subdirectory(SubD1)
#add_subdirectory(SubD2)
get_property(MY_SOURCES GLOBAL PROPERTY GlobalSourceList)
add_executable(myProg ${MY_SOURCES})
SubD1/CMakeLists.txt:
add_subdirectory(SubSubD1)
my_collect_sources(Source.cpp)
SubD1/SubSubD1/CMakeLists.txt:
my_collect_sources(Source2.cpp)
In your case there's no need to use add_subdirectory since you have only one target which is created in the root CMakeLists.txt. You can simply write this:
add_executable(myProg
SubD1/Source.cpp
SubD1/SubSubD1/Source2.cpp)
Use add_subdirectory for subdirectories creating their own targets so there's no information to pass upwards.