Custom Modules not fully respected?

General JUCE discussion
1

I might be doing this incorrectly but I’ve always had this issue when using a custom module:

I have JUCE as a git submodule.
I have a customised copy of one module (just for the AAX wrapper) - and the custom path (outside of /juce) is correctly set in Projucer.

But… it seems I need to fully delete (or rename) the original module in the original juce modules folder, or I’ll get ambiguity about which version of the file is being compiled. It’s a very strange behaviour as it seems like some of my custom code is used but at other times, the original code is being used. Weird.

My workaround of deleting the original module is OK, except that it’s seen as a change in the git submodule for JUCE - which is obviously a PITA, forcing me to go and make a special fork for myself.

So is this a bug in Projucer? Am I holding it wrong?

2

This is a non-standard use case, so it’s not surprising that you’re getting some strange behavior.

If you need to change any of the actual JUCE code, I would recommend either forking JUCE or applying a git patch file.

3

Oh, I’d somehow got the impression this was standard practice - otherwise what’s the reason for the per-module paths in Projucer?

Sounds like a fork is the way forward.

4

As far as I know, the Projucer supports having JUCE in a directory that is outside your project’s source tree, and it also supports adding your own additional custom modules. To my knowledge, providing alternate implementations of JUCE’s core modules is not intended to be a supported feature.

5

It was intended originally to mix and match modules from different paths.
However since the module root is added to the include search directory (afaik) you cannot use that approach any more (I think for a long time already).
It is also a nightmare to replicate bugs when you find them, if the developers need to find that particular combination of modules. So it is better to have a consistent set of modules.

I agree it would be good to remove the individual path settings for the modules, since they are a legacy and seemingly not always working. But the focus is now on cmake anyway, where this setting doesn’t exist anyway.

6

I’ll cast a vote here for a more flexible way of extending the plugin wrappers. There’s no way to use a subclass of the AAX wrapper is there?

7

I am not a maintainer of the code, so I don’t have as much say in it.

Maybe if you tell your use case there could be a way.
Otherwise the way is forking indeed.

Good luck.

8

This definitely sounds like a case for forking to me.