Linux C++ project directory layout - CMake - c++

I would like to use some standard layout for my linux c++ project which is built using cmake and contains some executables and a library that these execs might link to. Currently I just had a folder for the project and a sub folder for each sub project. With a CMakeLists in the top level and one in each sub level that the opt level adds.
Project-
executable1
executable2
library
However I think it would be better setup like the following
Project -
lib //Library output folder
bin //Executable output folder
src //Al cpp source files
include //All header files
test //All tests
I would have just one CMakeLists in top level.
I can easily set this up in cmake. does anyone have reasons for choosing a different layout?

I wouldn't put the lib, bin and test output directly on the project directory: if you want to make a debug and a release build, you get stuck, because you have only one placeholder. Out of source build is your friend! I would use something like:
Project
src
include
CMakeLists.txt
These will be generated when using cmake:
Project_build_dbg
bin
lib
test
Project_build_release
bin
lib
test

The layout you are proposing to use is pretty much how most of the projects are organised. And its a very well organised way of having a project. I usually also have a docs folder wherein goes all the documentation about the project. So heres my usual project setup.
Project -
lib //Library output folder
bin //Executable output folder
src //All cpp source files
include //All header files
test //All tests
docs //All project documentation ------> new addition

Related

Visual Studio C++ how to add header files in a prefix folder

I cloned a github C++ repository. The repository is not a VS project. So I manually created a VS C++ blank project and added the files from the repo to the project. The files are not copied. This is not the problem.
The repo directory looks like this:
include\NTL\*.h
src\*.cpp
*.h means a bunch of header files and *.cpp means a bunch of .cpp source files.
The problem is that the .cpp files have #include <NTL/*.h> and when I build, VS fails to locate the header files (No such file or directory). Adding the path to the include to the Include Directories in project properties didn't help.
EDIT: After some experimenting, I've found that the error has nothing to do with the prefix NTL in #include <NTL/*.h> but with whether the files are copied into project directory. Even though the files appear in VS project view, they must be copied into the project directory.
EDIT: The only way I've managed to get the project to compile is to put the whole NTL directory containing header files in project directory. Include Directories and Additional Include Directories in project properties don't seem to have any effect.
All previous No such file or directory errors were the result of some combination of:
Mismatching project properties Configuration and Platform
Some .h files were actually missing from NTL github repo, e.g. mach_desc.h.
The solution to the problem consists of the following:
Under project Properties > C/C++, add the path to the include to Additional Include Directories.
VS project has a separate set of properties for each combination of Configuration and Platform. Make sure that step 1 applies to the active Configuration and Platform. E.g. If the project's currently configured to build for Debug x64 (active Configuration:Debug and Platform:x64), make sure that step 1 applies to Debug x64, and not something like Release Win32 or Release x64, etc.
Use the Windows/Linux-specific zip package from the Downloads page of the official website https://libntl.org/download.html

Proper CMake project configuration

I am looking for a guideline regarding handling files that are not source files.
My project is a simple OpenGL application which uses shaders which is built using CMake.
Shaders are in seperate files with .vert .frag extensions respectively and those files are together with others in "src" folder.
Now, these shader files are read when .exe runs I am using Microsoft's C++ compiler, which creates adjacent folder to my src called "build" and in this folder, there is a folder containing my executable called "Debug".
So the structure looks like this:
|
|-src: main.cpp, default_shader.vert, default_shader.frag, etc.
|-build
|- Debug
|- main.exe, [and here I need to have my shaders]
My question is: How do I automate in a neat way moving shader files from my source directory
to this Debug folder?
I was thinking of adding custom target that would run batch file or maybe changing storage of the shaders from files with .vert/frag to something different.

How to create a simple CLion C++ CMake project with different locations for Project itself, build products and source files

I'm new with CLion and CMakeList. I'd like to have different locations for:
CLion project files
Build Files
Source and Header Files
When opening default projects all are located under the same directory tree
What are the steps to create such project ('Hello world')?
CLion project files
AFAIK, you can only set one global path for each jetbrains' IDE, by writing IDE_HOME\bin\idea.properties file.
Details can be found here.
Build Files
Settings -> Build, Execution, Deployment -> CMake -> Generation path
You can also set several paths for different build profiles there.
Source and Header Files
Add sources and include directories in CMakeLists.txt .

Using cmake to include my source files to another existing project

I'm trying to extend an open source project with my own source files, so that the executable being produced includes my code as well. Probably it's very easy, but somehow I'm overlooking it.
The build process is using cmake and the open source project contains a well written CMakeLists.txt. Instead of adding my source files in the directories of the open source project (and possibly changing CMakeLists.txt of the open source project), I prefer to separate my code in its own directory as follows:
src/opensourceproject/src/...
src/opensourceproject/include/...
...
src/myaddition/include/...
src/myaddition/src/...
Is there a way to wrap the build process and create a CMakeLists.txt that builds opensourceproject with my sources added to the opensource build? The reason why I want it, is that I'm more or less writing a plugin and I want my code to be present in the produced executable.

CMake solution sub-directory

I have a big CMake solution which contain 5 projects. On this 1 project creates Main executable and rest of the 4(3 static + 1 dynamic) projects creates libraries which are linked to the main project.
MainSolution:
|-MainExecutablePrj
|-StaticLib_1Prj
|-StaticLib_2Prj
|-StaticLib_3Prj
|-DynamicLib_1Prj
The entire project is to be build for both windows and linux platforms. Now I need to create an Sub directory under MainSolution and create some testcase projects which uses the DynamicLib_1 (.lib/.so). So far what I have done is I will have different solution for each test cases and copy the required .h files and .lib(.so) files and build the test case solutions.
Its very hard for me to maintain the source code and whenever there is an change on the dynamic library I need to copy all the necessary files and rebuild the test cases again.
So I wanted to include the Test cases solutions inside my main project, so that whenever I change dynamic library project it builds the test case projects as well.
I very well know to add those test case solutions as projects under the MainSolution but I wanted to create sub-directory and put all the test case projects under that folder.
MainSolution:
|-TestCasesFolder
|-TestCase_1Prj
|-TestCase_2Prj
|-...
|-MainExecutablePrj
|-StaticLib_1Prj
|-StaticLib_2Prj
|-StaticLib_3Prj
|-DynamicLib_1Prj
Can someone help me on this
It should not be necessary to copy any files.
Let CMake find the built libraries with find_library and add a hint to the path of subdirectories build folder
Let CMake include the header files from your subproject with include_directories. Add a prefix to make it platform independent.
Regarding the tests:
All unit tests for a subproject should be places within the structure of this project and not in the root project. Place all integration tests in the root project or a separate test project as part of the root project.
Example Structure