How to Include an Entire Source Tree


#1

I was wondering if there was an easy way to include and entire source directory and have the IDEs (xcode, visual studio) point to it without adding every file individually.  Like you can add juce modules.  I was using the code as a separate shared/dynmaic library but would really like to just compile all of the source in for each platform.   


#2

The Introjucer project / “Files” Tab / Right-Click / “Add Existing Files…” / Then select the top most folder.

?


#3

Or just drag-and-drop a folder into the introjucer's treeview.


#4

Great, Thanks.  This is a life saver.  As is the entire library ....whenever I need to do something a bit "off the beaten path", you have already anticipated it and included functions to perform these tasks (or made it easy to override).  

Excellent Library,

Thanks for creating it.


#5

It would be extremely helpful if there were a way to do this programmatically from the command line, so that we could update all of our plugin projects at once when a new file is added to the common library. That isn’t possible currently is it?


#6

No… but if you put your shared code into a juce module format, the format is designed to take care of that kind of thing.


#7

Hey Jules- thanks for the feedback. We actually did convert our library to a module early last year but abandoned it almost instantly because it was significantly slowing development. Any time we would edit a .cpp file in the library (which is pretty often because it’s still in active development), Xcode would trigger a full recompile as opposed to a shallow build. It would also index constantly and generally overheat our machines. Any advice, or should we simply deal with the folder juggling until our library is more stable?

I see the command line jucer tool “–fix-broken-include-paths” so it seems like it would be relatively simple to add something similar which would recursively add folders/files to the jucer project. And/or if there were a checkbox on folders in Projucer that would do this when the project was resaved. That would be amazing.


#8

Well, if you’re constantly changing header files then modules do have the disadvantage of being included in all your files, but otherwise they work really well for overall build times if you get your ratio of headers to cpps right.


#9

I’m a big fan of the module format, apart from it being a really easy way to include code across projects, it quietly promotes a much better coding style of separating components and programming in a more generic, library orientated way.

However, the whole project re-builds can be annoying when you’re simply modifying some inlined methods or do a git-pull etc.

I’ve been wondering if there is way modules can be included on a more opt-in basis and I don’t think this would be too hard to do.
• In the Projucer you’d just have a box next to the module that you could tick to “Generate separate header”
• If this is ticked it wouldn’t get added to JuceHeader.h but it’s own file would be created that looked like below:

module_name.h

#pragma once
#include "AppConfig.h"
#include <module_name/module_name.h>

• Then, in your app code you could simply include the module where required, like you would boost or the STL. E.g. #include <module_name.h>
• The search path would already be included because it’s within /JuceLibraryCode/
• The JUCE_MODULE_AVAILABLE_module_name is still defined in AppConfig.h
• An eventually we could ditch this an use C++17’s __has_include (<module_name.h>)

I think this should work but I’ve not fully tested it yet. Can anyone spot any obvious holes?


Request for Narrower Module Including (to improve build times and avoid whole-project recompilations)