Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Remove using namespace juce and juce module headers from generated JuceHeader.h #140

Open
rsjbailey opened this issue Oct 14, 2021 · 0 comments

Comments

@rsjbailey
Copy link
Contributor

rsjbailey commented Oct 14, 2021

Currently, the whole juce namespace is imported into files which make use of the framework.
This is generally not great practice, and has begun to make the project sensitive to #include ordering, as there's a potential conflict with the Point struct in the macOS CoreFoundation framework and the juce::Point class.

We should

  • Remove using namespace juce; from JuceHeader.h.in
  • Go through all headers that #include "JuceHeader_Wrapper.h"
  • Explicitly qualify the juce classes used in our interfaces
  • For each .cpp file, decide whether it's appropriate to import the juce namespace or whether we should selectively import names from that namespace.

The same header has #include directives for every juce module in the project, which is likely not optimal for compilation times as not all classes use all modules.

We could probably improve this fairly rapidly by

  • Copy/Pasting these #includes into each class header
  • Removing them from JuceHeader.h.in
  • Running include-what-you-use

I've never actually tried include-what-you-use and I'm not sure how clever it is, maybe you can skip step one or perhaps there's an additional step required to move some includes into the .cpp file when possible.

It probably makes sense to do the namespace qualification before the second stage, as if we already have ambiguous lookup I'd imagine include-what-you-use is going to struggle.

rsjbailey added a commit that referenced this issue Feb 10, 2022
* Updated JUCE submodule
* Update license for JUCE 6
* Include VST sdk as subproject
* Add VST sdk target to imported JUCE::VST3 target
* Add newly required macos frameworks to JUCE::core target
* Change NativeMessageBox useages to reflect JUCE API changes
* Reorder some headers to avoid issues with imported juce namespace (see issue #140)
* Add /bigobj flag on windows to prevent build errors
rsjbailey added a commit that referenced this issue Feb 11, 2022
* Updated JUCE submodule
* Update license for JUCE 6
* Include VST sdk as subproject
* Add VST sdk target to imported JUCE::VST3 target
* Add newly required macos frameworks to JUCE::core target
* Change NativeMessageBox useages to reflect JUCE API changes
* Reorder some headers to avoid issues with imported juce namespace (see issue #140)
* Add /bigobj flag on windows to prevent build errors
rsjbailey added a commit that referenced this issue Feb 14, 2022
* Updated JUCE submodule
* Update license for JUCE 6
* Include VST3 sdk as subproject
* Add VST sdk target to imported JUCE::VST3 target
* Patch VST3 SDK to add missing cmake configs
* Patch VST3 SDK to remove ide folder modification
* Add newly required macos frameworks to JUCE::core target
* Change NativeMessageBox useages to reflect JUCE API changes
* Reorder some headers to avoid issues with imported juce namespace (see issue #140)
* Add /bigobj flag on windows to prevent build errors
rsjbailey added a commit that referenced this issue Feb 15, 2022
* Update to JUCE 6.1.5

* Updated JUCE submodule
* Update license for JUCE 6
* Include VST3 sdk as subproject
* Add VST sdk target to imported JUCE::VST3 target
* Patch VST3 SDK to add missing cmake configs
* Patch VST3 SDK to remove ide folder modification
* Add newly required macos frameworks to JUCE::core target
* Change uses of NativeMessageBox to reflect JUCE API changes
* Reorder some headers to avoid issues with imported juce namespace (see issue #140)
* Add /bigobj flag on windows to prevent build errors
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant