On Fri, May 15, 2020 at 6:42 PM John Scott <jsc...@posteo.net> wrote:
> On Sat, 25 Apr 2020 21:40:14 -0400 FeRD <ferd...@gmail.com> wrote: > > If Debian maintains JUCE as a distro package, and it would be a > compatible > > alternative to our JUCE-based "libopenshot-audio", I don't see any > reason we > > can't add an option to libopenshot's CMake configuration that tells it to > > just > > use those libs, completely replacing libopenshot-audio ? which would > > become entirely superfluous in that scenario. > Looking at the https://salsa.debian.org/multimedia-team/juce repo, along with https://packages.debian.org/source/sid/juce, the impression I get is that Debian JUCE now has the form of a module-source package, to be used when building JUCE-dependent software, in keeping with the norms for how JUCE applications are typically used. (It looks like there used to be a libjuce until 5.2.0, since juce-module-source "Replaces: libjuce-dev (<< 5.2.0~)".) Given that, it seems we'd still want to build libopenshot-audio, still using our config headers and JuceLibraryCode/include_<module>.cpp wrappers, but with the include path set to /usr/share/juce/modules/ instead of using the bundled JuceLibraryCode/modules/. That made things even simpler than I expected, honestly. So, to that end, I've already both submitted and merged two PRs: https://github.com/OpenShot/libopenshot-audio/pull/97 https://github.com/OpenShot/libopenshot/pull/515 ...Which, taken together, allow libopenshot-audio to be configured with a CMake command line specifying an alternate path to the JUCE modules: cmake -DJUCE_MODULES_PATH=/usr/share/juce/modules Configured that way, it'll use that directory to build the modules and install the necessary headers. The JuceLibraryCode/modules dir in the distribution could even be deleted. (The outer JuceLibraryCode directory and its contents are still needed, as it contains ProJucer-generated files that aren't part of Debian's package.) The libopenshot PR was necessary because we were previously patching JUCE to work around an issue building our Ruby bindings. To make libopenshot-audio compatible with Debian's unpatched sources, I had to figure out the CORRECT way to work around that issue from the libopenshot end. I did, and PR 515 applied it. But if not building the Ruby bindings, libopenshot-0.2.5 release sources should build just fine against a libopenshot-audio built from non-bundled JUCE module sources. libopenshot-audio commit 25ca2d0 merged[1] the changes to our CMake setup, obviously this hasn't been incorporated into a release yet. If that's a problem, I can start banging the drum to roll an 0.2.1 release with JUCE_MODULES_PATH support. [1]: https://github.com/OpenShot/libopenshot/commit/25ca2d0dd83e9a0ecc961df8b2fa87a69ba2cd36
