There are a number of extensions, like the eps import,
that only become available when ps2pdf is available.
https://gitlab.com/inkscape/extensions/-/blob/master/eps_input.inx#L6
This is not so obvious, and this PR adds ghostscript (which provides ps2pdf)
explicitly so those extensions are always available and using a stable
version instead of relying on the PATH.
This will increase the inkscape closure by about 60MB,
which is quite a chunk, but perhaps not too bad on a
total of 1100MB.
We can't update inkscape to 1.0 without keeping 0.x in tree,
because the CLI interface has been changed and lots of packages
use this interface for SVG conversion.
Cairo is also a dependency now.
/tmp/nix-build-inkscape-0.92.4.drv-0/inkscape-0.92.4/src/display/drawing-context.h:20:10: fatal error: 'cairo.h' file not found
#include <cairo.h>
^~~~~~~~~
1 error generated.
Resolves#68185.
The icons in Inkscape depend on gdk-pixbuf loaders, but because
strictDeps is set to true to fix some macOS issues it doesn't work
(see #56943). Adding librsvg to buildInputs explicitly fixes the issue.
This uses strictDeps to get our args passed to the linker low enough
to enable building inkscape. With strictDeps we need to correctly use
nativeBuildInputs to avoid an issue.
This should not be needed because they are using `#!/usr/bin/env python` as the shebang and in fact it will break inkscape.x86_64-darwin.
https://hydra.nixos.org/build/73283875/
The first problem that was introduced in a276d5160c
was a linking error:
ld: cannot find -licui18n
ld: cannot find -licuuc
ld: cannot find -licudata
So I added icu to the buildInputs.
The second problem was that the interpreter wasn't patched in
share/filters, apparently this is only needed when building with
autotools:
make[3]: Entering directory '/build/inkscape-0.92.3/share/filters'
./i18n.py ./filters.svg > ./filters.svg.h
./i18n.py: /usr/bin/env: bad interpreter: No such file or directory
A similar error also occurs for share/palettes, share/patterns,
share/symbols and share/templates, so I added patching the interpreter
there as well.
Switching to autotools in Inkscape is a very bad idea, because upstream
currently still has their own autotools files in the 0.92.x tree but
master already has them removed, see this commit:
e471a664f9
However for the sake of trying to not break Inkscape on Darwin again,
I tried to keep the fixes minimal and not went back to CMake.
I did however mark the stuff that's unneeded for CMake, so that we can
avoid forgetting to remove that crap once we get back to CMake.
Signed-off-by: aszlig <aszlig@nix.build>
Cc: @matthewbauer
