Is it a too crazy idea? I have a sample small plugin using cmake and I’m using a copy of the juce release folder inside the source code tree to include all juce framework, etc…
Does it sound too crazy to use a git submodule to do this? I was thinking on using the official github master branch as a submodule on my own git plugins code. Does the main branch of the JUCE git repository follow the same structure as the official release?
Makes a lot of sense, especially when you setup automatic builds and continuous integration.
I develop usually on my machine with one central juce repository, and create later a repository, where I add the plugins and a juce clone, and directly in that repository I add the scripts for automatic building. That way I always have the choice to clone just the project or the whole self contained folder.
Only disadvantage is you have to update the submodules manually (for releases this is an advantage to control which commit you used last time).
To make its a very sensible choice, that’s exactly how I do it
Yes
Thanks!!
Not crazy. I assumed that’s what everyone do.
On that note, I always wished the modules folder was a submodule in the juce repository, so I could add only the modules to a project.
But this way has advantages as well, usually my CI scripts start with building the Projucer, calling Projucer --resave and so on.
With the cmake option it starts to be interesting again to have the modules folder separated…
IDK, just throwing it in for discussion/consideration.
You might want to consider taking a fork of the main repo and using that as your submodule. Using a fork will allow you to fix or modify the juce code as you need and I think it’s also helpful for submitting pull requests to the main repo, although I’m not certain about that as I’ve never actually done that.
I always add juce as submodule to my projects too.
In case that can be useful to someone :
git submodule add --depth=1 https://github.com/juce-framework/JUCE.git
and then to get the develop branch :
cd JUCE
git remote set-branches origin develop
git fetch --depth 1 origin develop
git checkout develop