Use git submodules for library dependencies

[per-gron]

This may or may not be something that you want to incorporate, but I personally find it an improvement. Instead of implicitly relying on the libraries being in certain folders within the superfolder of the project, add them as git submodules.

This is more or less equivalent to the current setup, except that the description of how to install the dependencies is precise and machine readable. It also has the benefit of storing the versions of the dependencies in version control, so it will be easier to keep track of and handle API breakages.

Your personal workflow may have to change a little bit, since you no longer can share the same madronalib checkout over separate projects. That may be a pain, but it also has benefits, since you get better control when you do breaking changes.

In order to clone the project on Google Code, I used http://svn2github.com/, which may or may not be regarded as sufficiently secure, since it introduces another third party that has to be trusted. On the bright side, if the code is audited on each submodule bump, it is secure, since the submodule bump refers to a specific SHA1 hash of a commit.

[per-gron]

The other thing that needs to be done in order to make it possible to just get the repo and go is to remove your code signing identity from the Xcode project. I recommend having that configuration in an xcconfig file that you can have locally, I'll see if I can come up with something nice.

[madronalabs]

I agree that building is not sufficiently precise or automatable now. What if we can address that pain in other ways?

Madronalib is not very much code, and I find my current workflow with it to be straightforward. With it in a separate directory I can quickly compile all my plugins / apps that depend on it, and test that I am not breaking anything.

Tying my build to a specific commit of JUCE does look like a good use for a submodule. I'm eventually moving away from JUCE, but that may be some time yet. Let me learn more about submodules, and test out your approach with JUCE.

Osctools and oscpack are both tiny and well past active development, so it may make sense to simply copy them into madronalib.

I'll look at fixing the code signing thing ASAP and will appreciate any input.

[per-gron]

I'm sure this can be addressed in other ways, this was just something quick I threw together as I tried to understand how the build system is set up.

Submodules are a somewhat obscure git feature, but they are actually very nice to use in the case of including other projects that you rarely change as part of working on the current project. I think they are hard to beat in cases such as the JUCE, osctools and oscpack libs, it is even quicker than just copying the libraries into the repos, in particular with updates and keeping track of them.

My main concern would be that newcomers to this project may find the use of submodules confusing. I personally don't think it's that difficult but I'm biased, having used and abused them a lot. Other approaches, such as downloading dependencies as part of a configuration step, will probably be more complex. Unfortunately, I think there is nothing like npm and npm link for C++.

Madronalib is different though, I can definitely see your concern there. Since soundplane is the only public user of madronalib, you could simply let the madronalib submodule checkout be your canonical checkout and add a symlink from where you have it now to that folder. That way, your current workflow will be more or less the same, you can do git operations as usual from the symlinked path as well. The difference then would be that you need to update the submodule reference when you push changes in soundplane that need newer madronalib changes. git status will remind you of this by not saying "working directory clean" if you haven't done the bump. I don't think you'll get rid of that step anyway if you want reproducible builds.

I'll post another PR with a suggestion for how to deal with code signing.

[madronalabs]

Thanks for the additional thoughts. I will leave the submodules PR open and try some tests out when I can.

-Randy

On Mar 10, 2015, at 10:45 AM, Per Eckerdal notifications@github.com wrote:

I'm sure this can be addressed in other ways, this was just something quick I threw together as I tried to understand how the build system is set up.

Submodules are a somewhat obscure git feature, but they are actually very nice to use in the case of including other projects that you rarely change as part of working on the current project. I think they are hard to beat in cases such as the JUCE, osctools and oscpack libs, it is even quicker than just copying the libraries into the repos, in particular with updates and keeping track of them.

My main concern would be that newcomers to this project may find the use of submodules confusing. I personally don't think it's that difficult but I'm biased, having used and abused them a lot. Other approaches, such as downloading dependencies as part of a configuration step, will probably be more complex. Unfortunately, I think there is nothing like npm and npm link for C++.

Madronalib is different though, I can definitely see your concern there. Since soundplane is the only public user of madronalib, you could simply let the madronalib submodule checkout be your canonical checkout and add a symlink from where you have it now to that folder. That way, your current workflow will be more or less the same, you can do git operations as usual from the symlinked path as well. The difference then would be that you need to update the submodule reference when you push changes in soundplane that need newer madronalib changes. git status will remind you of this by not saying "working directory clean" if you haven't done the bump. I don't think you'll get rid of that step anyway if you want reproducible builds.

I'll post another PR with a suggestion for how to deal with code signing.

— Reply to this email directly or view it on GitHub https://github.com/madronalabs/soundplane/pull/4#issuecomment-78107912.

[per-gron]

Don't feel any pressure on this, I do not mind at all if you just close it. I now know how to set up how the folder structure to build it so I'm good :)

[madronalabs]

I moved code signing for the Soundplane app into my own deploy scripts separate from the repository.