[Bug]: JUCE headers can fail guarding themselves against macros defined by windows.h

[danra]

trafficstars

Detailed steps on how to reproduce the bug

1. Start an example GUI application on Windows
2. Add the following to MainComponent.h:

#include <juce_core/juce_core.h>
#include <windows.h>
#include <juce_gui_basics/juce_gui_basics.h>

Get 20 errors (tested in VS2022) due to the min and max macros not being undefined properly (which JUCE does try to do, both by using NOMINMAX and by #undefing them in a few places). Replacing juce_gui_basics with juce_gui_extra gives even more errors due to the standard small macro being used as an enum value in juce_PushNotifications.h.

My attempted analysis at why JUCE's defenses aren't working properly:

• juce_core.h is first included. JUCE_CORE_INCLUDE_NATIVE_HEADERS is not defined, so native/juce_BasicNativeHeaders.h isn't included and so neither is windows.h. juce_core.h then undefines the standard small macro on its own and some more macros in juce_StandardHeader.h, but since windows.h wasn't included these aren't defined anyway.
• windows.h is then included without the useful WIN32_LEAN_AND_MEAN, NOMINMAX etc.
• juce_gui_basics.h is then included, but juce_core.h of course isn't included again because of the #pragma once. So none of the #undefs happen, and the standard Windows macros interfere with the JUCE definitions.

The above example is of course artificial, but we did actually get this in a more realistic scenario (also simplified here):

foo.cpp:

#include "foo.h"

#include "bar.h"

#include <juce_gui_extra/juce_gui_extra.h>
...

Header bar.h:

#pragma once

#include <juce_audio_processors/juce_audio_processors.h>

#include <third_party.h>
...

Header third_party.h:

...
#include <windows.h>
...

What is the expected behaviour?

Including a juce module, followed by including windows.h, followed by including another juce module should always work.

Operating systems

Windows

What versions of the operating systems?

all

Architectures

x86_64

Stacktrace

No response

Plug-in formats (if applicable)

No response

Plug-in host applications (DAWs) (if applicable)

No response

Testing on the develop branch

The bug is present on the develop branch

Code of Conduct

• [X] I agree to follow the Code of Conduct

[mkruselj]

We also have this happening in Shortcircuit XT, constant warnings about NOMINMAX macro redefinition. We traced it to juce_BasicNativeHeaders.h not having a guard around that #define NOMINMAX at around line 80-something.

Would be nice if this were guarded 🙂