[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#925754: Fwd: Fixed in newer release of libopenshot / libopenshot-audio





On Fri, May 15, 2020 at 6:42 PM John Scott <jscott@posteo.net> wrote:
On Sat, 25 Apr 2020 21:40:14 -0400 FeRD <ferdnyc@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

Reply to: