Sorry if I'm not being very clear. What I'm talking about is geared toward libraries which use angle brackets internally and are contained within the module's own folder structure rather than being referenced by some arbitrary filesystem location. An example of this is if a module is hosted on some git repo with a bunch of code written in the typical fashion specifically for that module (i.e. JUCE-style code) but it depends also on some other library that may be included as a git submodule within the module directory, say under something like /module_root/thirdparty/some_git_repo. some_git_repo may have its own folder structure, with files which require some_git_repo/include to be added to the header search paths in order for self-referencing include paths in some_git_repo to compile.
Here's an example of what I mean that will hopefully help illustrate. I have a JUCE module I'm working on, called my_module. It looks and acts just like every other JUCE module we're all familiar with. It uses all relative paths, for its includes, the .h/.cpp files have all the module's files listed, etc.
my_module
| components/
| math/
| native/
| util/
| juce_module_info
| my_module.h
| my_module.cpp
We find out we need a set of linear algebra functions to do some stuff in our math code, so we decide to use an open source library to do that. This library has a bunch of stuff like CMake, doxygen, config scripts, tests, and other stuff we don't necessarily need or want, but it's under active development so we want to embed it as a submodule within our module so we're always up-to-date and don't have to worry about copying it or maintaining it. We put it in a folder called thirdparty, where we will put all submodules like this.
my_module
| components/
| math/
| native/
| thirdparty/
| liblinalgebra/
| CMakeLists.txt
| doc/
| liblinalgebra/
| detail/
| functions.h
| liblinalgebra.h
| LICENSE
| README
| util/
| juce_module_info
| my_module.h
| my_module.cpp
So long as we're careful about how my includes are handled, we should theoretically be fine. However, there's an issue with how the include paths within liblinalgebra work that keep things from working smoothly - liblinalgebra.h includes functions.h by using angle brackets!
// @file liblinalgebra.h
#pragma once
#include <liblinalgebra/detail/functions.h>
...
Now, when the headers of liblinalgebra try to compile, their includes can't be resolved since the necessary include path isn't being searched. This is where my request comes in - it would be really nice if there was a JUCE module parameter that allowed for defining module-relative header search paths that would get resolved into project-relative search paths when saving/opening with a IDE from the Introjucer. In this example, a module manifest parameter would define the extra include path relative to the module root as thirdparty/liblinalgebra. Then, the Introjucer would add <relative module path> as it already does, but also add <relative module path>/thirdparty/liblinalgebra as requested by the module manifest. Now when it's time for liblinalgebra to resolve it's functions.h include, it's able to find it!
Hopefully that clarifies what I'm trying to ask. Sorry for being so unspecific before, this question/request really needed an example to convey what I'm trying to do.
And it gave me some some