JUCE won't build - latest dev tip on XCode 11

that is all the text, in the image.

i’ll try some example projects.

hi, ok so demorunner builds ok.

so it must be my projects.

any ideas? all I did was pull the latest…

I had this too. Some new Apple library seems to have a Point class as well. I now use juce::Point instead of Point. This works fine.

i don’t actually directly use the Point class in any of my code so I’ve got none to change to juce::Point.

Ah, maybe there was even a juce class, where I had to change it. Sorry, I can’t look this up, now. But you’re right this is not nice…

This is why I always set the DONT_SET_USING_JUCE_NAMESPACE macro in my projects.
“using namespace” should be banned.

For future reference, you can view the logs in a bigger window by clicking the ‘speech bubble’ button in the left toolbar (this is what it looks like with an artificial error):


Then, if you click the ‘lines’ button on the right, you can see the full compiler invocation, and all the command output, in a selectable/copyable view.

To fix your problem, look for any places in your code where you’re including Mac framework headers, or other third-party headers before JuceHeader.h, and make sure JuceHeader.h is included first. If changing the include order doesn’t work, just add a juce:: prefix to all the Point uses that the compiler complains about.

As @masshacker said, if you have some free time and want to avoid this kind of thing in the future, set DONT_SET_USING_JUCE_NAMESPACE=1 in the preprocessor defs of your project and add explicit juce:: namespaces everywhere.

adding JuceHeader.h everywhere where there’s a problem doesn’t work:

Not sure where I can change Point to juce::Point as this is just doing header preprocessing that causes the problem…

My best guess is that there’s a using namespace juce; somewhere before the include of CoreMidi.h, perhaps in lmh_audio_app.h, lmh_midi.h, or lmh_Processor.h. You could try grepping for using namespace juce in your custom modules and remove any uses that occur at global scope in headers.

ok, so I have a number of “using namespace directives” in my module header files.

So I should remove from the module header file and then go and individually add to every single header file I have? That’s obv alot of work so just want to make sure that that’s what you’re suggesting?

Yep, the most robust solution would be to remove using namespace juce from your module (or other) headers, and then to explicitly qualify any functions/types from juce headers with juce::.

It might also be that it’s possible to ‘fix’ this issue by adjusting your include order, so that CoreMIDI.h is included before any using namespace juce uses. This is not such great practice though, and if Apple or other third-party libraries add more identifiers at global scope in other headers, you might run into the same situation again.

Using using namespace before an #include will always lead to pain, and you should definitely avoid doing that. Relevant Core Guidelines rule here.

ok, just so I’m getting this right, from now on I have to qualify every use of any juce class with juce::, so I can’t write String anymore, I have to write juce::String everywhere…???

That’s the best approach. It’s what I do in my non-juce projects.

But like Reuben said: the problem is that you’ve got a using namespace followed by including some random system header. That’s never going to be safe. If you really really have to use using namespace then it MUST only be followed by your own code, and not by other 3rd party code that it could easily screw up.

And it’s not really possible to do this in a module header, because the modules get included in an unknown order in JuceHeader.h, and using statements in one module header might ‘leak’ and adversely affect the following headers.

So yeah, avoid using namespace in module headers.

what do you mean by non-juce projected? anything that isn’t core juce?

so any project I do is a non-juce project, and every time i ever use a juce class, enumeration or anything i need write an extra 6 characters of juce:: onto everything ? i thought namespaces were supposed to help use reduce the amount of typing we do as well as partition spaces, not cause us to write extra characters everytime we wan’t to use anything…

Yeah, sorry, I just meant anything that’s outside the actual juce codebase itself.

An example of compromise is the huge tracktion engine module, where it’d take days to replace all the uses, so we added juce:: to all the uses in the header files, but each cpp file has its own using namespace juce; inside it, after all the includes. That’s pretty safe, but still something we should go back and tidy up one day when bored.

oki, I’m convinced…

“what did you do in lockdown?”

“wouldn’t you like to know…”

1 Like

I’d like to add in light of the recent discussions on use of auto, using auto means you have to spell out juce:: far less than you would have before we had the feature.

2 Likes

yep, whilst I’m going through I’m taking the opportunity to put in auto where it can be - thx

that was not fun!