# FR: Add explicit includes to JUCE modules **URL:** \ **Category:** Feature Requests\ **Created:** [October 29, 2023, 2:06pm UTC](https://forum.juce.com/t/fr-add-explicit-includes-to-juce-modules/58552 "2023-10-29T14:06:55Z")\ **Posts on this page:** 20\ **Page:** 1
**Author:** ![eyalamir](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/eyalamir/32/2978_2.png) [@eyalamir](https://forum.juce.com/u/eyalamir)\ **Post date:** [October 29, 2023, 2:06pm UTC](https://forum.juce.com/t/fr-add-explicit-includes-to-juce-modules/58552/1 "2023-10-29T14:06:55Z")
Currently, IDEs have trouble parsing JUCE code due to the lack of explicit includes in modules. This is detailed in many discussions on the forum, for example here: > [@Adding Visual Studio Code code completion](https://forum.juce.com/t/adding-visual-studio-code-code-completion/44190/27): > > Worth bearing in mind the sheer number of native source files in JUCE - it’d be a real pain to have to manually go through on each platform adding the required includes to every single file. Also makes it difficult to maintain in the future as new files need to be included. As @reuk said, the best way to tackle that would be with a tool (something like [include-what-you-use](https://github.com/include-what-you-use/include-what-you-use)) that can fail a pipeline if a file isn’t including the right headers. @eyalamir Checked out your example there and it doe… This change is non-breaking, will _not_ change the unity builds system, and can be done in a few hours of work. It would be a major lifestyle improvement for all devs using JUCE, and probably to devs working on JUCE, too. ---
**Author:** ![Elanda](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/elanda/32/7752_2.png) [@Elanda](https://forum.juce.com/u/Elanda)\ **Post date:** [October 29, 2023, 2:11pm UTC](https://forum.juce.com/t/fr-add-explicit-includes-to-juce-modules/58552/2 "2023-10-29T14:11:31Z")
Hello peepls! I strongly second this! Anyone who thirds this? ---
**Author:** ![daniel](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/daniel/32/790_2.png) [@daniel](https://forum.juce.com/u/daniel)\ **Post date:** [October 29, 2023, 4:17pm UTC](https://forum.juce.com/t/fr-add-explicit-includes-to-juce-modules/58552/3 "2023-10-29T16:17:26Z")
third! btw it is much easier, no tool required. just remove the juce\_foo.h from the juce\_foo.cpp and start adding… A drawback could be that currently it is guaranteed that all config defines are included thanks to the master module header ---
**Author:** ![eyalamir](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/eyalamir/32/2978_2.png) [@eyalamir](https://forum.juce.com/u/eyalamir)\ **Post date:** [October 29, 2023, 4:21pm UTC](https://forum.juce.com/t/fr-add-explicit-includes-to-juce-modules/58552/4 "2023-10-29T16:21:08Z")
> [@daniel](#): > > A drawback could be that currently it is guaranteed that all config defines are included thanks to the master module header This should be guaranteed too: 1. Add some header file like config.h add all the ‘external’ includes to it, as well as #define macros. 2. Make sure each .h file either includes `config.h` or another .h file that includes `config.h.` 3. Compile to verify - not having those includes in the path will very likely prevent compilation, you can also compile existing projects and unit tests to double-check. ---
**Author:** ![reuk](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/reuk/32/21494_2.png) [@reuk](https://forum.juce.com/u/reuk)\ **Post date:** [October 29, 2023, 5:09pm UTC](https://forum.juce.com/t/fr-add-explicit-includes-to-juce-modules/58552/5 "2023-10-29T17:09:40Z")
Previously discussed here: > [@Adding Visual Studio Code code completion](https://forum.juce.com/t/adding-visual-studio-code-code-completion/44190/24): > > Maybe I’m missing something. Imagine that we have this setup: a.cpp, uses symbols from | x.h | y.h b.cpp, uses symbols from | x.h | y.h | z.h module.cpp, contains #include "a.cpp" #include "b.cpp" Now, we try building the module. We start by adding the x.h and y.h headers to a.cpp and rebuild. There are no build errors in a.cpp, but we see some undefined symbols in b.cpp. It looks like the z.h header is missing from b.cpp, but we don’t get any warning that x.h and y.h are also used in that … I stand by my assertion that it is _not_ straightforward to add all of the necessary explicit includes. Doing this the naive way (removing includes of .h files from the top-level module .cpp, then adding them to inner .cpp files until the build works again) is not guaranteed to produce correct results, because includes in ‘earlier’ .cpp files will still be visible in ‘later’ .cpp files. Moving all internal includes to a “config.h” file that gets included in every .cpp is not guaranteed fix this problem. If the config.h gets forgotten in any .cpp that appears later on in the top-level .cpp, the module will still build because of transitive includes through earlier .cpp files. It also sounds like completion in VS Code may also currently be broken for JUCE headers, too (can anyone verify?). Therefore, we’d need to ensure that each internal header _also_ included all the necessary dependencies, which again would be difficult due to transitive includes. I think the only way to guarantee correctness would be to add a non-unity build mode for each module, and to test that mode in CI in combination with other commonly-used preprocessor options. This would take much longer than a couple of hours to put together, and would incur substantial ongoing maintenance costs. In short, I’m not convinced that the benefits outweigh the costs. It also seems as though any benefits would mostly apply when working on first-party JUCE modules, so I’m interested to hear some concrete examples of problems that would be fixed by this change. ---
**Author:** ![eyalamir](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/eyalamir/32/2978_2.png) [@eyalamir](https://forum.juce.com/u/eyalamir)\ **Post date:** [October 29, 2023, 5:17pm UTC](https://forum.juce.com/t/fr-add-explicit-includes-to-juce-modules/58552/6 "2023-10-29T17:17:35Z")
Thank you for your suggestion @reuk. I understand your concerns about the ‘perfect’ way to do this with a tool that would 100% guarantee such a change would indeed include all needed .h files. However, since this a change that even if done without 100% proofing of that would dramatically improve the day-to-day life of all JUCE devs, My suggestion is to make that change ‘naively’, and just incrementally fix the very rare undetected issues that would happen as a result. I suggest that since the ‘worst case scenario’ here would be a few red squiggles that are left on a handful of .cpp files (and probably reported by the community and fixed fast), while the upside would be that most JUCE files would work just fine as-is. > [@reuk](#): > > In short, I’m not convinced that the benefits outweigh the costs. It also seems as though any benefits would mostly apply when working on first-party JUCE modules, so I’m interested to hear some concrete examples of problems that would be fixed by this change. Currently because of this problem, IDEs (even “high end” ones like CLion) sometime ‘screw up’ things like go-to definition. It’s also a big problem when browsing JUCE code. auto complete and other IDE refactoring tools are randomly breaking because of this, etc. ---
**Author:** ![eyalamir](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/eyalamir/32/2978_2.png) [@eyalamir](https://forum.juce.com/u/eyalamir)\ **Post date:** [October 29, 2023, 5:24pm UTC](https://forum.juce.com/t/fr-add-explicit-includes-to-juce-modules/58552/7 "2023-10-29T17:24:37Z")
> [@reuk](#): > > It also sounds like completion in VS Code may also currently be broken for JUCE headers, too (can anyone verify?). Therefore, we’d need to ensure that each internal header _also_ included all the necessary dependencies, which again would be difficult due to transitive includes. That is just due to VS Code naively trying to recursively parse headers. It may find `juce_Component.h`, but it might not be able to find `juce_String.h` Even though they’re all included in transitive includes of `juce_gui_basics.h`. That is also what’s causing IDEs like Xcode/CLion/etc to spin up a lot more memory to find how to index functions like `Component::getName()` and eventually put them in the auto-complete box, as usually these IDEs cache the database of a header by parsing it and then parsing all #includes coming from it recursively. ---
**Author:** ![eyalamir](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/eyalamir/32/2978_2.png) [@eyalamir](https://forum.juce.com/u/eyalamir)\ **Post date:** [October 29, 2023, 5:32pm UTC](https://forum.juce.com/t/fr-add-explicit-includes-to-juce-modules/58552/8 "2023-10-29T17:32:11Z")
To simplify, here’s my suggestion: 1. Do the change ‘naively’ (just add the includes, remove `#include module.h` from `module.cpp`). 2. Test builds exactly the way they’re tested now. If this change would somehow cause a user reporting an error due to a combination of flags, that probably means a test for that set of flags needs to be added to CI anyway. 3. Make the change incrementally, starting with simple high level modules like `juce\_product\_unlocking’, ‘juce\_osc’, ‘juce\_dsp’ etc, splitting this into well encapsulated PRs so that over time that change would lead to a great benefit the JUCE community as a whole, many of which have reported the problems caused by this for years. ---
**Author:** ![LukeM1](https://avatars.discourse-cdn.com/v4/letter/l/b3f665/32.png) [@LukeM1](https://forum.juce.com/u/LukeM1)\ **Post date:** [October 31, 2023, 10:49am UTC](https://forum.juce.com/t/fr-add-explicit-includes-to-juce-modules/58552/9 "2023-10-31T10:49:45Z")
> [@reuk](#): > > It also sounds like completion in VS Code may also currently be broken for JUCE headers, too (can anyone verify?). There were recent reports of Visual Studio and Intellisense being broken when parsing JUCE module code, but this has been fixed and is awaiting release (linked below). Perhaps this fix will also apply to VS Code. [https://developercommunity.visualstudio.com/t/Intellisense-Errors-in-CPP-File-underli/10114557](https://developercommunity.visualstudio.com/t/Intellisense-Errors-in-CPP-File-underli/10114557) ---
**Author:** ![eyalamir](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/eyalamir/32/2978_2.png) [@eyalamir](https://forum.juce.com/u/eyalamir)\ **Post date:** [October 31, 2023, 11:07am UTC](https://forum.juce.com/t/fr-add-explicit-includes-to-juce-modules/58552/10 "2023-10-31T11:07:55Z")
> [@LukeM1](#): > > There were recent reports of Visual Studio and Intellisense being broken when parsing JUCE module code, but this has been fixed and is awaiting release (linked below). Perhaps this fix will also apply to VS Code. Those aren’t related. I experience these issues in CLion all the time. The problems aren’t just VS-code specific. It breaks a lot of IDE systems, including go-to-definition, auto-complete and others. For example many JUCE .cpp files in CLion look like this (no type highlighting, can’t use go-to-definition, etc): ![Screenshot 2023-10-31 at 1.05.03 PM](https://us1.discourse-cdn.com/flex026/uploads/juce/original/3X/7/6/769bbf27d51c9a0e327eee185a8e5924fafcda82.png) This issue happened in my own modules too: ![Screenshot 2023-10-31 at 1.07.14 PM](https://us1.discourse-cdn.com/flex026/uploads/juce/original/3X/a/6/a6a113ff869ac8bd5aa5a10c5c16a66537d0cac5.png) And solved instantly by adding includes. ---
**Author:** ![eyalamir](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/eyalamir/32/2978_2.png) [@eyalamir](https://forum.juce.com/u/eyalamir)\ **Post date:** [October 31, 2023, 11:15am UTC](https://forum.juce.com/t/fr-add-explicit-includes-to-juce-modules/58552/11 "2023-10-31T11:15:47Z")
Just for fun, here are other plenty of cases where similar problems were reported in all other IDEs: > [@Juce and XCode - Auto Completion is too slow](https://forum.juce.com/t/juce-and-xcode-auto-completion-is-too-slow/57818): > > Hi Guys, I am using juce 7.0.5 and Xcode 14.3, the auto completion is too slow for every xcode version I had ever used with juce. Anyone facing the same issues ? As I was followinf matkat music tutorials, his xcode auto completion seem faster in videos. What will be the solution ? > [@Intellisense broken for JUCE cpp files in solutions](https://forum.juce.com/t/intellisense-broken-for-juce-cpp-files-in-solutions/53002): > > Since some VS2022 update (I’m on 17.3.4 now), Intellisense is broken for all JUCE cpp files that don’t include headers and are included somewhere else (hence, most of them). Everything compiles, JUCE modules are shown in the solution explorer, and all headers are ok, but no external identifiers are recognized in the cpps. This happens in all solutions, including Projucer and AudioPluginHost, but not in CMake folders. > [@Visual Studio Error](https://forum.juce.com/t/visual-studio-error/48583): > > I started a new file and navigated to the main.cpp section. Visual Studio has already displayed 28 syntax problems to me. I didn’t even touch anything. What should I do? It goes on… Please @reuk. No other codebase in the world adds tests for a build system that isn’t supported just to add #includes for a few .cpp files. Adding those is non-breaking, simple to do (can be done per module in an isolated way), can be iterative and will probably be a huge improvement to the lives of everyone here. Let’s not make this more complicated than it is. Transitive includes is a common mistake that can happen in every C++ codebase out there (and it happened once in a while in my own code) and the fixes are trivial, similar to documentation errors or typos. Please consider fixing this as this has been reported many, many times by users in all OS’s and all IDEs, and I bet the JUCE team experiences this on a daily basis. ---
**Author:** ![anthony-nicholls](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/anthony-nicholls/32/1246_2.png) [@anthony-nicholls](https://forum.juce.com/u/anthony-nicholls)\ **Post date:** [October 31, 2023, 11:23am UTC](https://forum.juce.com/t/fr-add-explicit-includes-to-juce-modules/58552/12 "2023-10-31T11:23:01Z")
I think it would be nice to have a small concrete example of the actual problem so we know what we’re does actually fix the issue. There could be a lot of work for very little reward if we don’t understand the actual issue. Also I assume this is only while browsing JUCE implementation code? If users aren’t employing unity builds and they only browse the headers then it’s not an issue right? ---
**Author:** ![anthony-nicholls](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/anthony-nicholls/32/1246_2.png) [@anthony-nicholls](https://forum.juce.com/u/anthony-nicholls)\ **Post date:** [October 31, 2023, 11:24am UTC](https://forum.juce.com/t/fr-add-explicit-includes-to-juce-modules/58552/13 "2023-10-31T11:24:30Z")
It’s worth pointing out that any work to resolve it will also mean extra time to compile due to all the discarded headers. It would be good to understand the trade off too. ---
**Author:** ![eyalamir](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/eyalamir/32/2978_2.png) [@eyalamir](https://forum.juce.com/u/eyalamir)\ **Post date:** [October 31, 2023, 11:30am UTC](https://forum.juce.com/t/fr-add-explicit-includes-to-juce-modules/58552/14 "2023-10-31T11:30:27Z")
> [@anthony-nicholls](#): > > I think it would be nice to have a small concrete example of the actual problem so we know what we’re does actually fix the issue. There could be a lot of work for very little reward if we don’t understand the actual issue. Also I assume this is only while browsing JUCE implementation code? If users aren’t employing unity builds and they only browse the headers then it’s not an issue right? This issue is shown in many, many forum posts (see above). Easiest way to observe this is just browsing JUCE implementation files in VS Code, but also in CLion, Xcode, etc. > [@anthony-nicholls](#): > > It’s worth pointing out that any work to resolve it will also mean extra time to compile due to all the discarded headers. It would be good to understand the trade off too. That’s not true, it’s the other way around actually. Since the unity builds system won’t (and shouldn’t!) change, all it would mean is that in the same compilation unit (say, juce\_core.cpp) there would be a bunch of lookups for, say, `juce_string.h`. Since that file would have `#pragma once`, that call would do nothing. The compiler isn’t re-parsing a header that already exists in the same compilation unit. In the case of an IDE the result would mean dramatically faster auto complete and code cache, since the IDE knows to read include guards, which currently it will ignore. I’ve tested this suggestion in all my modules that at one point of time converted to explicit includes. Build times, IDE auto complete time, etc, became dramatically faster instantly. The C++ compiler (and all tools based on it, like clangd) knows how to work with trivially written .cpp files, including how to parse the preprocessor efficiently. ---
**Author:** ![anthony-nicholls](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/anthony-nicholls/32/1246_2.png) [@anthony-nicholls](https://forum.juce.com/u/anthony-nicholls)\ **Post date:** [October 31, 2023, 11:34am UTC](https://forum.juce.com/t/fr-add-explicit-includes-to-juce-modules/58552/15 "2023-10-31T11:34:00Z")
A `#Pragma once` costs it’s not entirely free, I grant you it’s probably minimal but we could be talking about a lot of them! ---
**Author:** ![eyalamir](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/eyalamir/32/2978_2.png) [@eyalamir](https://forum.juce.com/u/eyalamir)\ **Post date:** [October 31, 2023, 11:40am UTC](https://forum.juce.com/t/fr-add-explicit-includes-to-juce-modules/58552/16 "2023-10-31T11:40:52Z")
> [@anthony-nicholls](#): > > A `#Pragma once` costs it’s not entirely free, I grant you it’s probably minimal but we could be talking about a lot of them! 1. Not that many. For example, most juce GUI objects just need to `#include `. They don’t need to explicitly include `` that is a requirement of it. So what the compiler will have to parse is the “high level” include and it won’t need to even test for all the internal includes that are brought in as a part of this module. 1. As far as the compiler is concerned, there’s some `std::map` that tells the compiler to do nothing. You can benchmark this and see that even a million such lookups are probably in the time area of non-measurable difference 2. All of the above is related to a clean compilation. In an incremental compilation that’s done after only some files have been changed, the compile process would be much faster since unless you’ve changed something in the `#include` dirty list, the compiler can decide to do nothing. Currently, the current system is fast to compile as a whole but the compiler has to do a lot of work parsing the entire module for each change since it has no idea which headers from it can be completely ignored in the compile process. I suspect that the speed change of incremental compilations in modules would be something the JUCE team (or anyone writing custom JUCE modules) would also see instantly. ---
**Author:** ![anthony-nicholls](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/anthony-nicholls/32/1246_2.png) [@anthony-nicholls](https://forum.juce.com/u/anthony-nicholls)\ **Post date:** [October 31, 2023, 11:57am UTC](https://forum.juce.com/t/fr-add-explicit-includes-to-juce-modules/58552/17 "2023-10-31T11:57:17Z")
> [@eyalamir](#): > > For example, most juce GUI objects just need to `#include `. They don’t need to explicitly include `` that is a requirement of it. Correct me if I’m wrong but I expect Component will need plenty of other things included too. > [@eyalamir](#): > > In an incremental compilation that’s done after only some files have been changed, the compile process would be much faster since unless you’ve changed something in the `#include` dirty list, the compiler can decide to do nothing. > > Currently, the current system is fast to compile as a whole but the compiler has to do a lot of work parsing the entire module for each change since it has no idea which headers from it can be completely ignored in the compile process. > > I suspect that the speed change of incremental compilations in modules would be something the JUCE team (or anyone writing custom JUCE modules) would also see instantly. More than happy to be proven wrong here, but my understanding is that would only be true if we are _actually_ compiling the cpp files, that’s different to satisfying a few IDEs, at the end of the day we would still be compiling one large cpp file so if anything changes the whole thing has to be rebuilt. I would also be concerned but how certain preprocessor definitions and options are handled in headers you would effectively have t duplicate a bunch of this stuff in all the separate headers which runs its own risks. Obviously there are clean ways to break all this up but again that’s not a small amount of work it will take time. If I’m honest I think there are some shortcuts/hacks where you can make the compiler treat each file in the unity build as if it is itself is the unity build. So it will still take time but if it’s just the unity build style that is the issue for some IDEs then I think it would achieve that goal. ---
**Author:** ![ImJimmi](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/imjimmi/32/10843_2.png) [@ImJimmi](https://forum.juce.com/u/ImJimmi)\ **Post date:** [October 31, 2023, 11:58am UTC](https://forum.juce.com/t/fr-add-explicit-includes-to-juce-modules/58552/18 "2023-10-31T11:58:57Z")
Just to add a few other (potential) advantages: - Building with [`CMAKE_UNITY_BUILD=On`](https://cmake.org/cmake/help/latest/variable/CMAKE_UNITY_BUILD.html) is currently not possible without also _excluding_ JUCE from the Unity Build. - Is using `CMAKE_UNITY_BUILD=On` any faster/slower than JUCE’s own Unity Build solution? Perhaps’s JUCE’s `CMakeLists.txt` could set this by default if it is any faster. - It would be nice to not have to use the JUCE module format and instead include only the headers you need. Sometimes you end up bringing in loads of bloat only to use 1 or 2 JUCE APIs. Top-level library includes is considered a bit of an anti-pattern these days is it not? ---
**Author:** ![anthony-nicholls](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/anthony-nicholls/32/1246_2.png) [@anthony-nicholls](https://forum.juce.com/u/anthony-nicholls)\ **Post date:** [October 31, 2023, 12:03pm UTC](https://forum.juce.com/t/fr-add-explicit-includes-to-juce-modules/58552/19 "2023-10-31T12:03:43Z")
> [@ImJimmi](#): > > Is using `CMAKE_UNITY_BUILD=On` any faster/slower than JUCE’s own Unity Build solution? Perhaps’s JUCE’s `CMakeLists.txt` could set this by default if it is any faster. In theory JUCE should be faster as it should group closely related files together which overall reduces the amount of parsing required, as many of them will require the same headers. Don’t forget we need to support the Projucer too. I get there are benefits but only with costs too. If we switched JUCE away from unity builds we would suddenly have a lot of people complaining about the overall build times. Most users shouldn’t be changing JUCE source very often (ideally at all) so incremental builds shouldn’t be a big issue for most end users. ---
**Author:** ![eyalamir](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/eyalamir/32/2978_2.png) [@eyalamir](https://forum.juce.com/u/eyalamir)\ **Post date:** [October 31, 2023, 12:09pm UTC](https://forum.juce.com/t/fr-add-explicit-includes-to-juce-modules/58552/20 "2023-10-31T12:09:44Z")
> [@anthony-nicholls](#): > > More than happy to be proven wrong here, but my understanding is that would only be true if we are _actually_ compiling the cpp files, that’s different to satisfying a few IDEs, at the end of the day we would still be compiling one large cpp file so if anything changes the whole thing has to be rebuilt. Depends on what you change. If you changed `juce_somefile.cpp`, a rebuild of that module would have to happen. That won’t change with my suggestion one way or the other. However - if you modify `juce_button.h` and didn’t modifly `juce_component.h`, each module/unit would hit the `#pragma once` in `juce_component.h`, and stop there. There isn’t a need to reparse Component since the compiler knows for sure it hasn’t changed in all of the current contexts, which it doesn’t now. > [@anthony-nicholls](#): > > I would also be concerned but how certain preprocessor definitions and options are handled in headers you would effectively have t duplicate a bunch of this stuff in all the separate headers which runs its own risks. Obviously there are clean ways to break all this up but again that’s not a small amount of work it will take time. That shouldn’t change. To do that, you need to add another header file, `config.h` and have all headers in the module include it. That is a requirement and has to be done for code to not break. That is also how it works in pretty much all C++ code BTW, this isn’t special to JUCE. You have one header of that module with all the commonly needed preprocessors. > [@anthony-nicholls](#): > > I would also be concerned but how certain preprocessor definitions and options are handled in headers you would effectively have t duplicate a bunch of this stuff in all the separate headers which runs its own risks. Obviously there are clean ways to break all this up but again that’s not a small amount of work it will take time. No, you won’t have to duplicate anything. You will add a bunch of `#include config.h`, and that will have an include guard. All these stuff is really how it always works if you open any C++ codebase in the world (except for JUCE). > [@anthony-nicholls](#): > > If I’m honest I think there are some shortcuts/hacks where you can make the compiler treat each file in the unity build as if it is itself is the unity build. So it will still take time but if it’s just the unity build style that is the issue for some IDEs then I think it would achieve that goal. No need for such hacks. I’ve already shown in the discussion linked above that this is trivial to do. Here’s an example for `juce_osc`: > (This is from 2 years ago, but I’m happy to send an up to date PR focusing on simple modules like that). This change is really super super simple. You just add includes, add one `config.h` file for the common stuff, and remove the global module header include. The only module where this would take some major work is `juce_core` since there’s a bunch of system stuff there that would be need to be moved into their headers, but for all other modules it is something that can be done by the end of the day for the entire codebase. [Next page](https://forum.juce.com/t/fr-add-explicit-includes-to-juce-modules/58552.md?page=2)