Also begin to start work on cross compilation, though that will have to
be finished later.
The patches are based on the first version of
https://reviews.llvm.org/D99484. It's very annoying to do the
back-porting but the review has uncovered nothing super major so I'm
fine sticking with what I've got.
Beyond making the outputs work, I also strove to re-sync the packages,
as they have been drifting pointlessly apart for some time.
----
Other misc notes, highly incomplete
- lvm-config-native and llvm-config are put in `dev` because they are
tools just for build time.
- Clang no longer has an lld dep. That was introduced in
db29857eb3, but if clang needs help
finding lld when it is used we should just pass it flags / put in the
resource dir. Providing it at build time increases critical path
length for no good reason.
----
A note on `nativeCC`:
`stdenv` takes tools from the previous stage, so:
1. `pkgsBuildBuild`: `(?1, x, x)`
2. `pkgsBuildBuild.stdenv.cc`: `(?0, ?1, x)`
while:
1. `pkgsBuildBuild`: `(?1, x, x)`
2. `pkgsBuildBuild.targetPackages`: `(x, x, ?2)`
3. `pkgsBuildBuild.targetPackages.stdenv.cc`: `(?1, x, x)`
- Reverts the change to the monolithic `clingo` package in favor of the
previous split between `clasp` and `gringo` since `opam` works with
the latter but not (for some reason) with the former.
- Adds explicit non-support for Python in `gringo`. This is not necessary
for opam.
- Forces usage of the `std::to_string` functions in the C++ standard
library instead of the incomplete alternative implementations inside
of the `gringo` sources.
Depends on gringo but gringo is now maintained as part of the clingo
suite. This commit removes gringo (standalone) and replace it with
the latest version of clingo. This update follows closely the old
derivation for gringo (see 99e06fe).
The opam package manager relies on external solvers to determine package
management decisions it makes related to upgrades, new installations,
etc.
While, strictly speaking, an external solver is optional, aspcud is
highly recommended in documentation. Furthermore, even having a
relatively small number of packages installed quickly causes the limits
of the interal solver to be reached (before it times out).
Aspcud itself depends on two programs from the same suite: gringo, and
clasp.
On Darwin, Boost 1.55 (and thus Gringo) do not build, so we only support
Aspcud on non-Darwin platforms.
Vladimír Čunát