In that case I would expect many developers to have done so already.
What’s the case of your fork (YUP)?
“Best” practices and “right” ways of doing things are very subjective. JUCE’s module format is neither best nor worst, right nor wrong - it’s just one of several solutions.
If you’re writing your own modules then following the JUCE approach is perfectly fine (and if you’re using the Projucer I think it’s still a requirement?), as is using a different approach.
I have been busy lately, but this has been bugging me as well for some time. Definately on my todo list. Also, yup is truly open source, you can open a PR and contribute too, i can guarantee that it will be looked at and considered
1 Like
It’s not a requirement, you can write your code with explicit includes and it works just fine in the Projucer (better, actually, because your projects work better in the IDE).
The implicit includes in JUCE are not a solution to any problem, it’s more of misunderstanding of the original problem:
Usually to get a .cpp file to compile you just include the headers that it needs.
Technically, because JUCE only compiles a ‘meta’ module_name.cpp file, you can also make the includes be implicitly done through the module .cpp, but there’s no requirement to do that, and the compiler doesn’t care if it looks at MyClass.cpp to find #include “MyClass.h” or it finds the same include through module_name.cpp. The compiler just wants those headers included by the time it compiles some code that requires them in the .cpp
However, both the IDE (and the developer!) do care about this, especially because they can’t always know in advance how a .cpp file is going to be compiled, so solving that problem using the simplest and most ergonomic solution, is better IMO.
I did give this shot and it’s fairly straightforward.
I’ve also offered (that offer still stands) to do this for free and submit a PR, but I would only do this if there’s a good chance of that PR being reviewed and considered.
JUCE team, are you willing to let me do that? 
4 Likes
good one.
On a side note, this reminds me this:
Our stance on this hasn’t changed for at least a decade and in almost all cases attempting to merge community contributions is a poor use of the JUCE team’s time when that effort can be focused on something more valuable to the framework
It is stil not clear to me if you got this to work. Did you?
And if so, then why not make this available in your own JUCE fork? That would allow many of us to test these changes. It’s a no-brainer since these changes should be non-breaking.
First of all yes, I have both many custom modules shipping with regular, explicit includes, AND I’ve taken hobby attempts to refactor some built in JUCE modules like juce_osc, and even posted those in this forum a few years ago (that fork would likely now be out of date, since I didn’t update it with JUCE 8, etc).
However, it’s not worth it maintain a JUCE fork with that change IMO - even though most code changes are trivial, it touches every single source file in the library (and even adds some new header files), and it’s just not worth the effort unless you’re planning to never merge back JUCE updates again (which I do often).
Ok, but you did not refactor the entire framework, which is what I was asking. So I guess nobody has done so?
No idea. Since this is more of a quality of life improvement and with no value to the user, and it would be too hard to merge upstream JUCE update, I don’t think it’s worth it for a personal fork.
But (as you can see in the discussion above) I did send a PR refactoring a module to ‘prove’ that it works, isn’t breaking, compiles with the Projucer, etc. It took me about 10 minutes.
1 Like
But a git conflict only arises from changes to the same lines in a given file. So even if a fork changed every single file in the framework, one could still merge updates with no major problems.
Is this the reason why apparently nobody has refactored the framework? It seems that the quality of life improvement would be well worth the effort!
Yes, but my change completely changes juce_module.cpp and juce_module.h, so it would mean that every new .cpp and .h, and also almost every change to the internals of every single cpp file would require me to check that it still compiles, still has all the needed includes… git might notice that JUCE’s change is new from a ‘text’ perspective but it won’t fix the compilation problems.
Even though the change itself is very simple to do, since it changes all the files in the entire framework, it’s not worth it (for me) to do on my end and keep fixing JUCE with every new source file or include change they do in the old system.
2 Likes
Ah, got it. YUP is a great canditate then, as it’s a fork of a JUCE version which is no longer updated. Hopefuly @kunitoki gets around to doing it. It would be very interesting to see how much of an improvement a refactor actually brings.