Intended C++ project organization?

I’m trying to convert an existing C++ project to use Gradle. Currently code is organized in modules like:

src/base/
src/util/

There are many more modules, some of which produce executables, some of which produce libraries, but I will focus on just these two for the sake of brevity.

The “base” module has no dependencies. I was able to get it to compile just fine with gradle by remapping the source directory from “src/base/cpp” -> “src/base”. However I couldn’t get util to compile because it depends on some header files in base. When these header files are #included they are referenced as “base/BaseHeader.h”.

I did some reading and decided to try to reorganize the project how I think Gradle envisions it. This left me with:

src/base/cpp/
src/base/headers/
src/util/cpp/
src/util/headers/

Now I used the following gradle script:

apply plugin: 'cpp'
model {
    components {
        base(NativeLibrarySpec) {}
        util(NativeLibrarySpec) {
            sources {
                cpp {
                    lib library: "base"
                }
            }
        }
    }
}

This worked, but only after I changed:

#include "base/BaseHeader.h"

to

#include "BaseHeader.h"

I can certainly do this, but it seems like a step backwards because I’ve removed a degree of namespacing from my project. This probably is OK in practice, but it seems odd that I have to do this. Can anyone comment on the “right” way to do this? As a bonus, can anyone tell me how I can avoid having to change the project structure (leaving .h and .cpp in the same directory)? I’m assuming I can do this by just brute-forcing a -I flag into the compile, but this feels hacky. I’d like to be able to make the Gradle model aware of my project structure in a supported way.

Take a look at this page from the Gradle DSL reference:

Also, this is how to globally add src to the include path (brute-forcing?)

model { ...
}
tasks.withType(CppCompile) {
  includes "src"
}

Actually I don’t think the #include <packageName/headerName.h> style has long been accepted by the C/C++ community although I admit it has some virtues.

FYI, it’s confusing to use #include "" instead of #include <> when the included file is not in the same directory as the including file