Commit graph

14 commits

Author SHA1 Message Date
Felix Buehler 1e9baed56b various: cleanup of 'inherit version;' 2021-07-16 00:17:12 +02:00
Andrew Childs 7869d16545 llvmPackages: Multuple outputs for everythting
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)`
2021-04-30 05:41:00 +00:00
Ben Siraphob 8c5d37129f pkgs/tools: stdenv.lib -> lib 2021-01-15 17:12:36 +07:00
Profpatsch 4a7f99d55d treewide: with stdenv.lib; in meta -> with lib;
Part of: https://github.com/NixOS/nixpkgs/issues/108938

meta = with stdenv.lib;

is a widely used pattern. We want to slowly remove
the `stdenv.lib` indirection and encourage people
to use `lib` directly. Thus let’s start with the meta
field.

This used a rewriting script to mostly automatically
replace all occurances of this pattern, and add the
`lib` argument to the package header if it doesn’t
exist yet.

The script in its current form is available at
https://cs.tvl.fyi/depot@2f807d7f141068d2d60676a89213eaa5353ca6e0/-/blob/users/Profpatsch/nixpkgs-rewriter/default.nix
2021-01-11 10:38:22 +01:00
Michael Weiss 595a36d846
scons.py2: Replace with sconsPackages.scons_3_1_2
Required since SCons 4.0.0 doesn't support Python 2.7 anymore.
2020-07-18 10:48:20 +02:00
Michael Reilly 84cf00f980
treewide: Per RFC45, remove all unquoted URLs 2020-04-10 17:54:53 +01:00
Michael Weiss 0950324466 scons: Add passthru.py2 for backward compatibility
Not all packages build with Python 3, see #75877. The goal is to get rid
of Python 2 but this approach ensures a smoother transition.
2020-03-27 10:49:52 -07:00
volth 08f68313a4 treewide: remove redundant rec 2019-08-28 11:07:32 +00:00
volth c814d72b51 treewide: name -> pname 2019-08-17 10:54:38 +00:00
Matthew Justin Bauer bda7c2fd4b
gringo: use postPatch
patchPhase overrides the patches thing.
2018-06-25 11:45:18 -04:00
Winnie Quinn a1013287f3 gringo: add darwin platform support 2017-09-12 09:22:25 +02:00
Jesse Haber-Kucharsky 51b04c1bf5 Revert opam solver dependency changes
- 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.
2016-11-12 08:39:52 -05:00
Théo Zimmermann 93fbb947b3 aspcud: fix by updating the dependencies (#20086)
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).
2016-11-03 12:14:45 +01:00
Jesse Haber-Kucharsky 99e06fe771 opam, aspcud: init packages for external solver (#16938)
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.
2016-09-12 10:44:50 +02:00