Issue when mixing "regular" and "local copy" modules?

The Projucer
1

Using Xcode and Projucer 4.3.0.

I noticed that if I check the “Create local copy” only for some modules, then in the “Build settings” I have the following Header Search Paths:

../../JuceLibraryCode ../../../juce/modules ../../JuceLibraryCode/modules

The problem is that the include path for the locally copied modules (../../JuceLibraryCode/modules) comes after the one for those in the main JUCE folder (which live in ../../../juce/modules).

This means that, when the corresponding file in the JuceLibraryCode is processed (for example, the follwing:)

juce_opengl.mm:

/*
    IMPORTANT! This file is auto-generated each time you save your
    project - if you alter its contents, your changes may be overwritten!
*/

#include "AppConfig.h"
#include <juce_opengl/juce_opengl.mm>

The juce_opengl/juce_opengl.mm module that is included is not the locally copied one (inside ../../JuceLibraryCode/modules), but still the one inside the main JUCE source code at ../../../juce/modules.

I think this kinda misses the whole point of having local copies of the modules.
I suggest adjusting the Projucer so that the Header Search Paths for the local copies come before the one for modules inside the main JUCE code.

2

Hmm. The local copy thing is something I regret adding… It seemed like a good solution back in the days when a lot of people still refused to use GIT and wanted the projucer to handle getting/installing the juce code, but it seems silly and confusing now. Maybe something we should deprecate before too long.

3

I use a local copy (but globally)… that way I can maintain any changes I’ve made to the JUCE code.

Rail

4

@jules, I’m aware of your feeling towards the “local copy” thing and I don’t use it myself, but as you can see there are people who make good use of it and for a good reason.

Also, mixing local copies and non-local is obviously a bit of an edge case: I came to it only while tampering a bit with Projucer, and would not recommend to use it in any “real” project as it may lead to confusion.

Still, for the sake of formal correctness, putting the include path for the local copies before the one for the non-local modules seems the most logical thing to me.

5

I don’t think that just changing the order would work in every case, would it? I think mixing local/non-local is just inherently a messy thing to do…

6

I disagree, I believe that it would work in every case: module headers are always included with:

#include <juce_module/juce_module.h>

This is true in JuceHeader.h (regardless of whether the module is locally copied or not), and it is also the way other modules include the headers of the modules they required.

So, by putting the header path for local copies before:

  • If a module is locally copied then the header of the local copy will be used in every place where it is referenced.

  • If the module is not locally copied, then the corresponding header will not be found in the folder of local copies folder and the search for it will continue to the next path, the one of non-local copies, where it will be found and used.

(The order in which header paths are specified is important and followed by the compiler)

The case for the juce_module.cpp file is even simpler: that file is only included by the corresponding file inside JuceLibraryCode, so the statement that’s found therein:

#include <juce_module/juce_module.cpp>

will similarly refer to the local copy if it is there, and to the non-local one if that’s the only one existing (i.e. the module is not copied locally).

That’s agreed upon, but that should not stop you from doing what’s formally correct in that case.

1 Like