In preparation for the deprecation of `stdenv.isX`.
These shorthands are not conducive to cross-compilation because they
hide the platforms.
Darwin might get cross-compilation for which the continued usage of `stdenv.isDarwin` will get in the way
One example of why this is bad and especially affects compiler packages
https://www.github.com/NixOS/nixpkgs/pull/343059
There are too many files to go through manually but a treewide should
get users thinking when they see a `hostPlatform.isX` in a place where it
doesn't make sense.
```
fd --type f "\.nix" | xargs sd --fixed-strings "stdenv.is" "stdenv.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "stdenv'.is" "stdenv'.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "clangStdenv.is" "clangStdenv.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "gccStdenv.is" "gccStdenv.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "stdenvNoCC.is" "stdenvNoCC.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "inherit (stdenv) is" "inherit (stdenv.hostPlatform) is"
fd --type f "\.nix" | xargs sd --fixed-strings "buildStdenv.is" "buildStdenv.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "effectiveStdenv.is" "effectiveStdenv.hostPlatform.is"
fd --type f "\.nix" | xargs sd --fixed-strings "originalStdenv.is" "originalStdenv.hostPlatform.is"
```
with structuredAttrs lists will be bash arrays which cannot be exported
which will be a issue with some patches and some wrappers like cc-wrapper
this makes it clearer that NIX_CFLAGS_COMPILE must be a string as lists
in env cause a eval failure
This was added in 07d12fbef1 ("fontforge: get rid of output hash
depending on git"), to explain the line:
export GIT="$(type -P true)".
This line was removed in e9848d11ad ("fontforge: 20190801 -> 20200314"),
but I forgot to remove the comment.
Fixes: e9848d11ad ("fontforge: 20190801 -> 20200314")
refactor the debian patch to apply
still seems required to get the extra binaries
Co-authored-by: Jan Tojnar <jtojnar@gmail.com>
(suggestion for partial applying the fetched patch)
libungif was merged into giflib in 2006, and hasn't been updated
since. All non-broken packages still using it build fine with giflib.
See <http://giflib.sourceforge.net/history.html>.
It was unintuitive that the withGTK option controlled whether a
fontforge GUI was enabled at all, since fontforge supports multiple
GUIs (a GTK one and an X11 one -- confusingly the X11 one still
requires GTK).
With the new withGUI option, it is possible to build the X11 GUI by
setting withGTK to false and withGUI to true. I haven't added an
attribute for this configuration because I expect it to be pretty
obsure -- my rationale for adding this option was code clarity rather
than utility.
- Init libuninameslist at 20190701 as it is a new dependency to fontforge
- Remove gnulib, as it is not used anymore
- Remove a non-applying patch
- Add myself as maintainer
https://github.com/fontforge/fontforge/releases/tag/20190317
* add zmq (collab), woff2 (format), readline (cli)
* "just in case", keep determinism patching
* fontforge-fonttools: replace with override enabling tools
Don't see any reason to not include by default,
so this might make more sense as an alias instead.
- Things didn't work very well before, as libs were only dlopened and
not found. Fixes#5716.
- Newer releases need autotools to build (and git), leading to some bloat.
- Also, more things are installed by default, increasing the output size.
