Jump to content
  • Advertisement
Sign in to follow this  

C++ Engine/Library Header files relative include path

Recommended Posts

I have an issue which is more related to code organization rather than a technical issue.

So, i'm developing my own game engine with c++ in visual studio and compile it as a static library so that i'm able to link it with a seperate visual studio game project.

I recently started to move some header/cpp files of my engine project/solution into subdirectories (in particular the renderer, so that i can call my include statements with "#include "renderer/VertexBuffer.h")

This works fine as i added my project directory ($(ProjectDir)) into my AdditionalIncludeDirectories in my engine solution.


Now, in order to access my engine in other VS projects, i link the Engine.lib with the Project and include all header files of the engine project. 

In order to make it visually clear which include statements are engine header files, i added the solution directory into the IncludeDirectories of the project.

(So that my statements look like this:"

//in headers of a gameproject
#include "Engine\ECS.h"
#include "Engine\Physics\PhysicsWorld.h"
#include "Engine\Physics\PhysicsDebugDrawer.h"

This works fine for all game project related include statements.

But now the game project throws include errors in all engine related header files which were included by the game project:

The issue is that they don't have "Engine\" in the include statements:

//in engine related header files:
#include "ECS.h"
#include "Physics\PhysicsWorld.h"
#include "Physics\PhysicsDebugDrawer.h"

So they work if i compile them in my Engine Visual studio project, but fail if they are included as external library headers.

One solution would be to include the paths of the solution and the project of my game engine:

D:\Projects\VisualStudio_projects\Engine\         //Solution Path (so that the game can access via #include "Engine/...."
D:\Projects\VisualStudio_projects\Engine\Engine   //Project path (so that engine headers can directly access stuff without #include "Engine/...

But this does seem to be a workaround rather than a proper solution.


What is cleanest solution to this problem? Any advice?

Share this post

Link to post
Share on other sites

I do the same for my engine SDK. I have my root folder that contains

|_ Config
|_ Engine
|_ Source
|_ Tools

and a generator tool that will traverse through those subfolders to find projects that relate to each other (like by the full or partial include paths). Those get linked together as additional include directories in the VS project file and the problem is solved.

For example my Crypto project relates to Core project. As Core is flagged as module directory, it will be taken otherwise it's parent directory will be taken. So the include directory for Crypto is it's parent and for Core is itself. The result leads to a module based include path for example

//included from Core
#include <Types.h> //<- from ./Engine/Core
#include <Math/Long.h> //<- from ./Engine/Core/Math

//included from Crypto
#include <Crypto/EcDsa.h> //<- from ./Engine
void EcDsa::GetPrivateKey(...)


Share this post

Link to post
Share on other sites

It's because that your game engine code and your game code are inconsistent with the including path scheme.

My favorite scheme is, in your game engine project, create folder "include/engine", then put all game engine related headers in "include/engine" and it's sub folder such as "include/engine/audio", "include/engine/ecs", etc.

Than in any projects, include the game engine itself, that are using the game engine, set the include path to "include", and the include code is same in all projects include the game engine, which is

#include "engine/a.h"
#include "engine/audio/b.h"


Edited by wqking

Share this post

Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  

  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!