On Sat, Apr 25, 2020 at 4:41 PM John Scott <jsc...@posteo.net> wrote:
> On Fri, 24 Apr 2020 23:33:59 -0400 FeRD <ferd...@gmail.com> wrote: > > What version of libopenshot is that result from? The Clang namespacing > was > > fixed with the merge of 2a1fe80[1] on 2019-10-29, and would be included > in > > both libopenshot-0.2.4 and libopenshot-0.2.5. > I used version 0.2.2+dfsg1-1 which is the current version in unstable. I'm > not > the maintainer; upgrading it is outside of my domain (esp. in light of the > following). > Ah, gotcha. Yeah, libopenshot 0.2.2's *tests* not building with Clang is a known issue, which has been fixed since 0.2.4. > Right, I know what'll pull it all together. It seems that the source for > libopenshot includes embedded code copies of JUCE, and code copies are > strongly discouraged in Debian, even if they don't make it into the > binaries. > That file is a Debian-specific README mostly addressed to developers that > says > to replace bundled copies of JUCE and use the code in package juce-modules- > source instead. This approach seems to have not been taken. > Understood. Well, looking at things from that direction, fortunately the bundled code is all sequestered into a separate package, libopenshot-*audio*, which libopenshot depends on. Really there's nothing to libopenshot-audio OTHER than a customized build of JUCE, to be honest. (Customized == pared down, mostly. We don't use any of the GUI components. So it's "JUCE but only these six modules: core, events, data_structures, audio_basics, audio_devices, and audio_formats.") 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. This is the perfect time to do it, too, as I've been gutting and reworking large parts of libopenshot's build system recently — sticking in a "USE_SYSTEM_JUCE" option would be no trouble at all. Is there an importable CMake configuration for the distro JUCE package, by any chance, or should I put together a find module as well? > > I hope this makes clear the nature of the obstacles ahead. It makes the *situation* much clearer, yes thanks — but so far I'm still optimistic that this is pretty easily solvable, really. Then again, I rarely see obstacles until I barrel into them at 50 MPH, so I guess we'll see how things go. ¯\_(ツ)_/¯
