The current version of `avidemux` (v2.7.0) breaks on master (see
https://hydra.nixos.org/build/75993794), the 18.03 build remains fine
(https://hydra.nixos.org/build/75935027).
The following changes have been applied:
* `glibc` compat patch is obsolete as it landed in upstream.
* Fixed QT_PLUGIN_PATH for QT binaries to avoid errors because of
missing plugins like this:
```
qt.qpa.plugin: Could not find the Qt platform plugin "xcb" in ""
This application failed to start because no Qt platform plugin could be initialized. Reinstalling the application may fix this problem.
[1] 20081 abort /nix/store/rjwxc6ih15zwvvy71ss8bvnh56ibfbmj-avidemux-2.7.1/bin/avidemux3_qt5
```
This drastically reduces the complexity of the `avidemux` derivation
and adds QT5 support (see #33248).
Rather than invoking `cmake` over preconfigured hooks, it's much easier
to use the `bootStrap.bash` script provided by the developers to do the
installation tasks. Furthermore this script makes it way easier to
configure which parts of `avidemux` should be used (e.g. CLI-only) or
without the plugins.
In order to create a CLI-only instance you can simply override the
derivation:
```
avidemux.override {
withQT = false;
}
```
It's possible to set the default executable as well (`avidemux` creates
a `avidemux_qt5` and `avidemux_cli` executable by default):
```
avidemux.override {
default = "cli"; # default is `qt5`
}
```
The GTK support has been dropped entirely since it was originally broken
in our system and can't be built ATM. Other distros such as ArchLinux
don't support GTK anymore (see https://git.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD?h=packages/avidemux#n64)
* pkgs: refactor needless quoting of homepage meta attribute
A lot of packages are needlessly quoting the homepage meta attribute
(about 1400, 22%), this commit refactors all of those instances.
* pkgs: Fixing some links that were wrongfully unquoted in the previous
commit
* Fixed some instances
stdenv.
In this gcc-wrapper2 I made the ld-wrapper.sh to handle the linking with shared
objects through direct pass as ld command arguments of the absolute path to shared
objects, instead of using the -L/-l combinations.
cmake 'FindXXX.cmake' modules make a strong usage of the dynamic linking directly
passing the absolute path to the shared object to the linker, and as our wrapper did
not add any -rpath for those, writting the nix expressions for some cmake packages
resulted in a lot of tricks, compared to using this gcc-wrapper2.
This gcc-wrapper2/ld-wrapper.sh should become the gcc-wrapper/ld-wrapper in a
stdenv update.
I also updated some cmake expressions to use this gcc-wrapper2, and reduced its
tricks.
I also updated the cmake setup-hook for it to make cmake not touch any rpath decided
at build time, when running the 'make install' of makefiles created by cmake.
svn path=/nixpkgs/trunk/; revision=18885
