Is there a way to require the directory name in Included Directories for include paths?

So, this question is more from a code organizational point of view, specifically when trying to isolate libraries and their header files (and gain help from editor IDE’s) as well.

Assume the project has a structure such as so:

src/
    core/
        core.h
        core.cpp
    math/
        vector.h
        vector.cpp
    json/
        json.h
        json.cpp
    .....

and we have core, math, and json setup libraries, with dependencies json -> core and math -> core.

Now, we would like to make our includes “start” from folder src/ in all cases, so we can easily tell which module they came from… for example

json.h:

#include "core/core.h"

math.h:

#include "core/core.h"

To do this, for json, core, and math, we would have their include_directories specified from src/. However this poses a problem - we lose a first line of defense against incorrect cross-includes. In such a case, we will only know there is an issue IFF the linker (not the compiler) does not know about the symbol (and as such there are cases when an incorrect cross-include passes unknowingly).

IE, there is a chance that if json.h is defined as such:

#include "core/core.h"
#include "math/math.h"

Then the build might still link (and it will definitely compile) in some cases when the stars align, which unfortunately happens quite often in large projects.

So one solution I can think of are to simply double-created the parent directory:

src/
    core/core/
        core.h
        core.cpp
    math/math/
        math.h
        math.cpp
    json/json/
        json.h
        json.cpp

Then, we can add the PUBLIC include directory to each of the library targets, and then in the case above, json.h would fail to compile as the math.h include would be unresolvable.

The downside to this is that you have a bit of an ugly directory hierarchy. If you are lucky and your IDE flattens empty folders, then that might be okay for you.

An additional benefit to this approach is that you could then have an additional private/ folder or something similar, such as:

src/
    core/
        core/
            core.h
            core.cpp
        private/
            some_private_include.h

and then add the private/ folder as PRIVATE include path to the library, preventing header/implementation leakage as well.

Another possible solution (?) that I stumbled upon would be to use, but am unsure of would be. IMPLICIT_DEPENDS_INCLUDE_TRANSFORM

It seems like it may be possible to take an #include "core/core.h" and remap it to simply #include "core.h", but then would run into file name collision issues.

I’d like to know what others opinions are on this matter, or maybe some other practices I haven’t thought of…

Thanks,
MS

One pattern I remember seeing from autoconf-using projects was to have, in each “project” directory, include/ with the includes and src/ with anything private. That avoids X/X problems at least by making it X/include/X.