search

sudara / pamplejuce

A JUCE audio plugin template. JUCE 7, Catch2, Pluginval, macOS notarization, Azure Trusted Signing, Github Actions
https://melatonin.dev/blog/
MIT License
394 stars 37 forks source link

Use CMake FetchContent to include JUCE #3

Closed ellapollack closed 3 years ago

ellapollack commented 3 years ago

This FetchContent call points to the current tip of the JUCE develop branch: 3f78998b967979da8523030ba76e807d4431efcd.

sudara commented 3 years ago

@maxwellpollack Oh hai! I've been cribbing off of your code as I work on the github action stuff :) It's been really useful!

I decided to go with a submodule for JUCE (Using FetchContent for Catch2 though) and just getting github actions to set the submodule up. I'm not sure it's the right call, but since this is meant as a template for a plugin, I felt like I'd probably be bumping the JUCE version during local dev (no need to re-run cmake, etc.) I'm curious how it feels managing the version in CMake tho!

ellapollack commented 3 years ago

Hey, nice to meet you! Was happy to see this repo pop up, seems like you're tying up a lot of loose ends I wish I had :)

That's a good point re: version management. I haven't found updating the JUCE version with FetchContent to be hugely inconvenient, because I've been on the master branch so updates have been relatively infrequent. But I imagine this could become quite tedious on develop! This makes me curious... what's your reason for tracking develop rather than master by default?

One option to make updating easier would be to change the GIT_TAG parameter to origin/develop rather than the commit hash. This would mean that every CMake config would update JUCE to the latest version, but would require the developer to swap in a commit hash or version tag when they want to "freeze" the version.

The main advantage of FetchContent over git submodules, in my eyes, was for beginners: git submodules require an extra step to download (e.g. git clone --recurse-submodules or git submodule update --init) whereas FetchContent is automatic. But evidently it's not without its downsides 😁

sudara commented 3 years ago

Hey, nice to meet you! Was happy to see this repo pop up, seems like you're tying up a lot of loose ends I wish I had :)

Ha! Nice to meet you too. Yeah, trying to nerd out once so I never have to nerd out again. Let's see if the strategy pays off :) I saw your repo a few months ago, but it wasn't until I got into the github action stuff that I really dug in — nice work!

This makes me curious... what's your reason for tracking develop rather than master by default?

I like pain! Er, maybe I will change my mind when I have plugins shipped... But the overall goal is to have a good enough build pipeline /test harness that the codebase doesn't have to feel brittle / scary to update, etc. So it's just to encourage that direction, which is one I'm used to coming from web dev stuff...

One option to make updating easier would be to change the GIT_TAG parameter to origin/develop rather than the commit hash. This would mean that every CMake config would update JUCE to the latest version, but would require the developer to swap in a commit hash or version tag when they want to "freeze" the version.

Ah, that makes sense.

The main advantage of FetchContent over git submodules, in my eyes, was for beginners: git submodules require an extra step to download (e.g. git clone --recurse-submodules or git submodule update --init) whereas FetchContent is automatic. But evidently it's not without its downsides 😁

Yeah, good point. I'm very friendly with git, so I underestimate this. Related, I've been wondering if it might be nice to structure the repo differently, still sorta chewing on whether this should be an example or if it would be possible to frame it as a dependency. Most ideally, I could have 5 plugins and they somehow point/include this repo for the test/build setup, so I don't end up with 5 copies of various versions of that code.