What happened to “Inclusion of the JUCE framework in package managers like vcpkg…” (from Announcing JUCE 6 | JUCE)?
3 Likes
Bumping this, is it still planned or…?
+1
We had planned to do this originally, but it ended up looking a bit difficult to keep everything up to date in all package managers. In the case of vcpkg, I think we would need to submit a PR to the vcpkg repo on each major JUCE version, so there would be a bit of a delay between releases becoming available on our github, and availability in package managers. This might be a bit of a problem in cases where we need to add hotfixes to master - ideally, we’d like users to be able to use these changes immediately.
We also encourage users to use our develop branch rather than the master branch during development. At least when I last checked, the process for using a custom branch with vcpkg was quite involved.
I also investigated the possibility of adding a Conan package for JUCE, but also ran into difficulties there. This was a while ago, so I don’t remember the details exactly, but I think ConanCenter had specific requirements on the format of contributed packages. IIRC, ConanCenter required all of the package contents to be listed in the package manifest (i.e. not a CMake file), but JUCE’s ‘module’ target type wasn’t supported in this manifest.
Since announcing JUCE 6, the CPM package manager has become a bit more popular. As I understand it, this package manager allows you to depend on arbitrary CMake projects, without requiring the maintainers of those projects to submit updates to any central repositories. I’ve heard of a few people using this approach with JUCE - perhaps it would work for you too.
We might take another look at adding a package to vcpkg if there’s sufficient demand. However, at the moment, I think grabbing the sources from github (maybe via CPM) is likely to lead to a better user experience.
5 Likes
+1
You can create your own vcpkg registry:
Creating registries | Microsoft Learn
which can just be hosted as a github repository. It would be great if JUCE supported this as it would make depending on it a fair bit easier and also reduce build times for users, particularly in CI. The JUCE registry could contain release builds as well as the most recent develop if you wanted people to be able to work against that easily.
It seems CMake and most IDEs are getting first-class vcpkg support so it feels like this is a good direction to move towards to help with adoption of JUCE.
2 Likes