There are separate derivations for these libraries and we don't want
conflict. Multitarget is generally more useful, and will eventually
speed up cross builds, so why not?!
One should depend on
- `stdenv.cc.bintools`: for executables at build time
- `libbfd` or `libiberty`: for those libraries
- `targetPackages.cc.bintools`: for exectuables at *run* time
- `binutils`: only for specifically GNU Binutils's executables, regardless of
the host platform, at run time.
On most distros, these are just built and distributed as part of
binutils. We don't use binutils across the board, however, but rather
switch between binutils and a cctools-binutils mashup, and change the
outputs on binutils too. This creates a combinatorial conditional soup
which is hard to maintain.
My hope is to lower the the state space. While my patch isn't the most
maintainable, they make downstream packages become more maintainable to
compensate. The additional derivations themselves are completely
platform-agnostic, always they always supports all possible target
platforms, and always yield "out" and "dev" outputs. That, in turn,
allows downstream packages to not worry about a dependency
shape-shifting under them.
In fact, the actual binutils package can avoid needing multiple outputs
now that these serve the requisite libraries, so that also can become
simpler on all platforms, too, removing the original wart this PR
circumnavigates for now. Actually changing the binutils package to
leverage is a mass rebuild, however, so I'll leave that for a separate
PR.
I do hope to upstream something like my patch too, but until then I'll
make myself maintainer of these derivations
Note that clasp (included in clingo) is already packaged separately, but
only an earlier version. As it is used by OPAM, but will stop being used
by OPAM later (and I want to grab the name for Clasp the Common Lisp
implementation), I decided to package clingo as a whole (as recommended),
but to leave clasp until OPAM stops needing it.
This package is most likely only used by Paperwork and thus it makes
sense to put it next to the main expression of Paperwork.
No functional changes here, evaluating before this commit and afterwards
leads to the same derivation hash.
Signed-off-by: aszlig <aszlig@nix.build>
Both Paperwork and its backend API are very likely to be updated in par,
but even when not whenever I work on Paperwork I'll check the backend as
well.
Signed-off-by: aszlig <aszlig@nix.build>
While updating Paperwork in 1b1cc34020 I
actually changed the GitHub URL to its new location.
However, the actual homepage of Paperwork is https://openpaper.work/ so
let's use that instead of the GitHub URL.
Signed-off-by: aszlig <aszlig@nix.build>
Reported-by: @volth
