Remove all inclusions within the module and move them into just the master module files.

[jrlanglois]

[nick-thompson]

In practice, I realize that this approach follows the JUCE module format, but I wonder as well, could this break CMake integration if users didn't want to use the builtin juce cmake helpers? That's maybe a dumb question anyway because users of this project must obviously be juce users :)

[jrlanglois]

It shouldn't have any different effect when building with cmake outside of a JUCE managed build context.

Practically speaking, users should only need to import the top level .h/.cpp into their cmake... Otherwise they would be stuck disabling compilation for the child files.

Either way, the chain of inclusions is the same no matter how you skin it!

[JoshMarler]

Personally I'd prefer not to do this as it breaks compatibility with some tools like clangs etc. That JUCE module/header approach isn't the most intellisense friendly approach. Do we need to follow it ?

[nick-thompson]

Agreed actually; at some point in the duktape refactor I remember actually going kind of the opposite direction and explicitly declaring include dependencies in each header file. It feels odd to me to delegate the business of include ordering to the juce module header file rather than explicitly declare dependencies at each header.

Generally, too, I think it's likely more valuable to support dev tooling & IDEs than it is to follow juce's header conventions.

I'll go ahead and close this accordingly, but do feel free to reopen if there's more discussion to have. Thanks @jrlanglois for starting the convo!