fix(juce): keep the module header includable under using namespace juce - #29
Merged
Merged
Conversation
|
The latest updates on your projects. Learn more about Argos notifications ↗︎
|
…uce` The SDK is header-only, so including moonbase_licensing.h drags the platform's system headers into the consumer's TU. On Apple those reach MacTypes.h and its global `Point`; on Windows, wingdi.h and its global `Rectangle()`. In a TU with a file-scope `using namespace juce;`, which is how HISE is written, each becomes ambiguous with the matching juce name, and MacTypes.h then stops parsing outright. Measured with clang against JUCE 6.1.3 and 8.0.4: 4 errors either way, in both include orders. Rename those system names out of the way around the system includes, with push_macro/pop_macro so a consumer's own Point/Component macros survive, and MOONBASE_DISABLE_SYSTEM_NAME_SHIM to opt out. This is the same trick JUCE uses in juce_audio_devices.cpp. Add tests/juce/global_using_namespace_juce.cpp to the existing JUCE test target: no other TU in this repo has a global `using namespace juce;`, so CI could not see this class of bug at all.
TobbenTM
force-pushed
the
hise-point-collision-macro-shim
branch
from
September 16, 2026 09:01
fcca908 to
b6fb733
Compare
github-actions Bot
pushed a commit
that referenced
this pull request
Sep 16, 2026
## [4.3.1](v4.3.0...v4.3.1) (2026-09-16) ### Bug Fixes * **juce:** keep the module header includable under `using namespace juce` ([#29](#29)) ([a126bd4](a126bd4))
|
🎉 This PR is included in version 4.3.1 🎉 The release is available on GitHub release Your semantic-release bot 📦🚀 |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Including
moonbase_licensing.hfrom a translation unit with a file-scopeusing namespace juce;, which is how HISE is written, does not compile today: the header-only SDK drags the platform's system headers into the consumer's TU, where Apple'sMacTypes.hPointand Windows'wingdi.hRectangle()become ambiguous with the matching juce names, andMacTypes.hthen stops parsing outright. Measured withclang -fsyntax-onlyagainst real JUCE 6.1.3 and 8.0.4 trees: 4 errors in both include orders before, 0 after.The fix renames those system names out of the way around the system includes, using push_macro/pop_macro so a consumer's own
Point/Componentmacros survive, withMOONBASE_DISABLE_SYSTEM_NAME_SHIMto opt out; it is the same trick JUCE uses injuce_audio_devices.cpp. The tradeoff, documented in the JUCE module guide, is that Carbon'sPointand GDI'sRectangle()are no longer reachable under their own names in a TU that includes the module header.tests/juce/global_using_namespace_juce.cppjoins the existing JUCE test target so every CI platform and supported JUCE version compiles this shape; no other TU in the repo has a globalusing namespace juce;, so CI could not see this class of bug.