[REQUEST] Adding additional header paths to JUCE modules


There's a few header-only libraries I'd like to use across all my projects which use angle-bracket inclusion exclusively (glm, glew) that I'd like to use in a JUCE module. At the moment I have to add each library via compiler arguments in the Introjucer for each platform I'm compiling for in every project I make. Is there a possibility that something like "additional include directories" could be added to the JUCE module format so I can lump everything into a handy JUCE module? Right now the only workaround I've found for this is to copy the libraries over and change all the angle bracket includes to relative include paths, which is obviously less than ideal.

Looking at jucer_AudioPluginModule.h from the Introjucer it looks like this is already kinda implemented, though hardcoded in for that case. It would be really nice if all modules could be configured like that in their module manifests.


It's not really possible to put an include path into a module definition, because the point of a module is that it should be position-independent. If there was a path in the manifest, then it would by definition only work on that particular machine.. (?)


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.

| 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.

| components/
| math/
| native/
| thirdparty/
  | liblinalgebra/
    | CMakeLists.txt
    | doc/
    | liblinalgebra/
      | detail/
        | functions.h
      | liblinalgebra.h
    | 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.


I see what you mean - I had a similar problem with some of the libraries that are embedded in juce (flac, libjpg etc) and ended up fixing them by manually changing all their internal include paths to be correct in relative terms. It never ceases to amaze me that people would layout the files for their libraries in such a way that their internal implementations break without the whole thing being on an include path. Grrrrr....

Anyway, what I'd actually recommend for this would be to use my new utility to do this automatically:


..that way these folders will always work, whatever project you add them to, without any messing about. 

(At the moment I think it ignores angle-bracket includes so may need a bit of tweaking if your libraries use that)

But yes, I'm willing in principle to take on board ideas like adding include paths for modules, just no time to get onto it right now!


Since you support implementing this idea, I'll add it locally and report back here with my changes when I'm done so you can focus on your higher priority things. Thanks Jules!


Okay, I implemented it. It's really nice to have this functionality! To use it in the module manifest, use the keyword "extraSearchPaths" and then list out the search paths relative to the module's root the same way the "browse" keyword is set up. i.e. for the example in my earlier post, add

"extraSearchPaths": [

And then the project exporter will turn these into project-relative paths for the resulting IDE project. Tested under VS2015 and Xcode 7. Git patch attached as a .txt, based on the current tip of master.


EDIT: Removed the attachment since those who needed to see it saw it and it had my raw email in it. PM me if you're a future reader who needs this diff.


Any feedback on this?


Seems like a sensible idea, but let me refactor the module stuff first.. If I forget to add it as part of the new system, remind me!


Will do, thanks. Super excited to see the new module system!!