Best way to extend JUCE for private projects

[Tabsel]

Hi,

I want to extend for example the VSTPluginFormat class. Easy, as this class is declared in a .h and defined in a .cpp, I simply derive from VSTPluginFormat…
Now I want to also extend the VSTPluginInstance and the ModuleHandle classes which are declared and defined in juce_VSTWrapper.cpp. Is there a reason that these classes are declared and defined in one cpp?
Now I can NOT derive from these classes.

I could
a) copy the file, put in my own namespace and modify the code, or
b) modify the file directly

I don’t like a), because I wont keep track of commits made to the juce_ module file, and I don’t like b), because it might pose substantial work to maintain pulls/merges from the development branch

What would be the preferred way of way more experienced JUCErs to extend JUCE code?

[jimc]

So sometimes I take a copy of the whole module and do modifications. But if I’m feeling fancy I:

• Fork a copy of JUCE
• Point my git submodule containing JUCE to the fork
• Change what I need, commit.
• Push the changes to a new branch on the fork I control

Then there are a bunch of options for getting JUCE updates, all of which require some git gymnastics, but I can rebase my changes on top of the latest JUCE, or cherry-pick JUCE patches on top of my existing branch.

This assumes you are using git, and have your JUCE library as a submodule of your project.

There ought to be an FAQ covering this stuff…

[yfede]

@Tabsel

Is there a reason that these classes are declared and defined in one cpp?

Usually, this happens in the JUCE codebase when the classes are just “implementation details”, and not really intended for public use.

I’m not an expert with these specific classes you mention, but if there is a good reason to make them public, you may expose your case and hopefully the JUCE team will listen.

Otherwise, I’d recommend proceeding in the same way @jimc also explained: make your own repository of JUCE forking the original, and apply your changes to that.

Doing it this way, you can regularly merge into your fork the changes that are applied to the official repository over time (or act with the rebase strategy, as it has been suggested, depends on your personal preference and possibly also on the extent of the changes you intend to apply).

I should also point out that for this to work, it is not strictly necessary that you have your JUCE repo as a submodule of some other project of yours: you can also have it as a separate working copy if that’s how you already use the official JUCE.

[jimc]

you can also have it as a separate working copy if that’s how you already use the official JUCE.

Although this is probably easier to set up it doesn’t lend itself to a reproducible build or keeping things in sync across two build machines.

[yfede]

Although this is probably easier to set up it doesn’t lend itself to a reproducible build or keeping things in sync across two build machines.

Yes yes, I totally agree and I do use it in a submodule myself, exactly for these reasons. It certainly is the solution I would recommend!

I pointed out the fact that a submodule is not strictly necessary for a didactic reason:
If the OP (or whoever ends up reading this topic) is not very familiar with git, then merges and rebases are already enough work to get familiar with. In that case, learning to work with submodules is a more “advanced” concept that can be saved for later, when enough confidence has been gained.

[jimc]

Submodules are pretty horrible.

I’ve found doing stuff with SourceTree rather than using git directly for non-trivial operations helps. But if anyone has other suggestions for great git tools I’m interested. I’d rather spend my time coding than crying in the corner with a git manpage and stackoverflow

[yfede]

I’m using submodules since so long that I got accustomed to them… they feel like second nature now, but I agree that in the beginning it has been a real pain to get them right (also because git was quite unfriendly for that!).

The git feature that now greatly surpasses submodules in terms of “horribility” is git LFS in my opinion. Good idea per se, but very fragile in its current implementation, and very very easy to get huge amounts of frustration from it (can get painfully slow when you have several small files handled by it, plus several other quirks). I’m hopeful it will improve over time.

As for GUI clients, I am also using SourceTree for regular operation and I am pretty satisfied by it, but I did my choice long ago and haven’t looked around much, would be interesting to know if some better app is in the field now (I considered the GitHub client, but I found it a little too bit “integrated” with the cloud service they provide).

However, let’s not steal this topic any longer, poor @Tabsel is probably wishing to have more opinions regarding his original question rather than git-rants .

[Tabsel]

Im trying my way with git subtree’s…
Any downsides to these?

[jules]

GIT submodules are what we use too. Everyone found them a real pain at first, but after a while you learn what you should and shouldn’t do, and they’re not too bad. Just don’t try to be too clever with them!