Hardcoded absolute paths to 3rd party binaries

[lukash]

Shotcut contains absolute paths to binaries it executes in various parts of its code, like this one: QFileInfo ffmpegPath(qApp->applicationDirPath(), "ffmpeg");

I assume the binaries are also packaged along with Shotcut in some way in the binary releases.

This however is causing trouble when packaging Shotcut for a Linux distribution by building from source and not bundling the binaries (which is desirable from package purity standpoint). On NixOS in particular (I'm not sure how other distros cope with this), it wouldn't even be possible to execute binaries built for common Linux distros, even if someone wanted to package it that way - which is not desirable anyway.

In NixOS it's currently handled this ugly and fragile way, which can break easily with a slight change to the source code:
https://github.com/NixOS/nixpkgs/blob/3c5cc34fac30437567fb71882c19112fbde27bee/pkgs/applications/video/shotcut/default.nix#L57

(here's a PR to update to the latest version: NixOS/nixpkgs#201905)

Could the paths to the individual binaries Shotcut uses be added to the CMake interface via defines, and only default to the currently used paths if not overriden by the build system? This would make the packaging job much easier and more robust.

(Or, for a simpler solution, a switch that would just use binariy names without a path, having them looked up in PATH. That should solve the issue at least for the general distro case.)

I understand the reason for the bundling is to ensure the binaries work well with Shotcut, there's probably a certain version range that's compatible for a given release. In addition to the above, if you wanted to provide the range of compatible versions for the packaging (which would certainly be useful), unless there's a better mechanism (I don't know of any), you could record the compatible versions somewhere in the documentation or the release notes?

Os: NixOS, version: 22.10.25

[ddennedy]

I will accept a PR for a build option to change or remove these paths that keeps the existing approach by default, but I will not be working on it.

We cannot recommend a range of compatible versions since we do not analyze or test for that. With that said, this is mainly limited to melt, ffmpeg and ffprobe. The version of melt is simple because Shotcut always requires the latest version of MLT. You can see our build script for the FFmpeg version we use, which is currently 5.1: https://github.com/mltframework/shotcut/blob/master/scripts/build-shotcut.sh
With that said, the ffmpeg command line has been fairly stable lately, and you are unlikely to encounter a problem unless VA-API or NVENC hardware encoders are not included.