There are several tarballs (such as the `rust-lang/rust`-source) with a
`Cargo.toml` at root and several sub-packages (with their own Cargo.toml)
without using workspaces[1].
In such a case it's needed to move into a subdir to only build the
specified sub-package (e.g. `rustfmt` or `rsl`), however the artifacts
are at `/target` in the root-dir of the build environment. This breaks
the build since `buildRustPackage` searches for executables in `target`
(which is at the build-env's root) at the end of the `buildPhase`.
With the optional `buildAndTestSubdir`-argument, the builder moves into
the specified subdir using `pushd`/`popd` during `buildPhase` and
`checkPhase`.
Also moved the logic to find executables and libs to the end of the `buildPhase`
from a custom `postBuild`-hook to fix packages with custom `build`/`install`-procedures
such as `uutils-coreutils`.
[1] https://doc.rust-lang.org/book/ch14-03-cargo-workspaces.html
I hate the thing too even though I made it, and rather just get rid of
it. But we can't do that yet. In the meantime, this brings us more
inline with autoconf and will make it slightly easier for me to write a
pkg-config wrapper, which we need.
Some PECLs depend on other PECLs and, like internal PHP extension
dependencies, need to be loaded in the correct order. This makes this
possible by adding the argument "peclDeps" to buildPecl, which adds
the extension to buildInputs and is treated the same way as
internalDeps when the extension config is generated.
flat hashes can be substituted through hashed-mirrors, while recursive
hashes can’t. This is especially important for Bazel since the bazel
fetch dependencies can come from multiple different methods (git,
http, ftp, etc.). To do this, we create tar archives from the
output/external directory, which is then extracted to build. All of
the Bazel hashes are all updated.
If a user provides `nativeBuildInputs = [ llvmPackages.bintools ]` or any other
package containing a `${prefix}/bin/diff`, the builder could use it instead
of the standard unix `diff`, causing a build failure.
This updates the call to specify an abspath to `diff` and avoid reliance on `PATH`.
Resolves#87081
Calculating the tarsum after creating a layer is inefficient, since
we have to read the tarball we've just written from the disk.
This commit simultaneously calculates the tarsum while creating the
tarball.
Appending to an existing tar archive repeatedly seems to be a quadratic
operation, since tar seems to traverse the existing archive even using
the `-r, --append` flag. This commit avoids that by passing the list of
files to a single tar invocation.
When running `cargo test --release`, the artifacts from `buildPhase`
will be reused here. Previously, most of the stuff had to be recompiled
without optimizations.
The only reason to pass build inputs is to extend the unpackPhase with
custom unpack commands. Eg: add "unrar" to unpack rar sources. And those
should really be passed as native build inputs. Why? Because
nativeBuildInputs is for dependencies that are used at build time but
will not propagate as runtime dependencies. And also, cross-compilation.
The build system already sets these properly to the absolute path so no
need to patch the libraries on darwin.
$ otool -D result/lib/liblapacke.dylib
result/lib/liblapacke.dylib:
/nix/store/k88gy5s765yn3dc5ws3jbykyvklm7z96-openblas-0.3.8/lib/libopenblasp-r0.3.8.dylib
Fixes#85713
Previously, callPackage would try and fill the arguments such as `name`
and `src` which would cause problems if those existed as top-level
attributes. This also makes it clearer what part is the function
signature.
Then document the derivation inline in the code to explain the ellipsis
and various use-cases.
This reverts commit b32a057425,
which breaks even the most straightforward uses of srcOnly:
nix-repl> srcOnly guile
error: anonymous function at /home/src/nixpkgs/pkgs/build-support/src-only/default.nix:1:1 called with unexpected argument 'drvPath', at /home/src/nixpkgs/lib/customisation.nix:69:16
nix-repl> srcOnly hello
error: anonymous function at /home/src/nixpkgs/pkgs/build-support/src-only/default.nix:1:1 called with unexpected argument 'drvPath', at /home/src/nixpkgs/lib/customisation.nix:69:16
Link: https://github.com/NixOS/nixpkgs/pull/80903#issuecomment-617172927
This is a better name since we have multiple 64-bit things that could
be referred to.
LP64 : integer=32, long=64, pointer=64
ILP64 : integer=64, long=64, pointer=64
This is based on previous work for switching between BLAS and LAPACK
implementation in Debian[1] and Gentoo[2]. The goal is to have one way
to depend on the BLAS/LAPACK libraries that all packages must use. The
attrs “blas” and “lapack” are used to represent a wrapped BLAS/LAPACK
provider. Derivations that don’t care how BLAS and LAPACK are
implemented can just use blas and lapack directly. If you do care what
you get (perhaps for some CPP), you should verify that blas and lapack
match what you expect with an assertion.
The “blas” package collides with the old “blas” reference
implementation. This has been renamed to “blas-reference”. In
addition, “lapack-reference” is also included, corresponding to
“liblapack” from Netlib.org.
Currently, there are 3 providers of the BLAS and LAPACK interfaces:
- lapack-reference: the BLAS/LAPACK implementation maintained by netlib.org
- OpenBLAS: an optimized version of BLAS and LAPACK
- MKL: Intel’s unfree but highly optimized BLAS/LAPACK implementation
By default, the above implementations all use the “LP64” BLAS and
LAPACK ABI. This corresponds to “openblasCompat” and is the safest way
to use BLAS/LAPACK. You may received some benefits from “ILP64” or
8-byte integer BLAS at the expense of breaking compatibility with some
packages.
This can be switched at build time with an override like:
import <nixpkgs> {
config.allowUnfree = true;
overlays = [(self: super: {
lapack = super.lapack.override {
lapackProvider = super.lapack-reference;
};
blas = super.blas.override {
blasProvider = super.lapack-reference;
};
})];
}
or, switched at runtime via LD_LIBRARY_PATH like:
$ LD_LIBRARY_PATH=$(nix-build -E '(with import <nixpkgs> {}).lapack.override { lapackProvider = pkgs.mkl; is64bit = true; })')/lib:$(nix-build -E '(with import <nixpkgs> {}).blas.override { blasProvider = pkgs.mkl; is64bit = true; })')/lib ./your-blas-linked-binary
By default, we use OpenBLAS LP64 also known in Nixpkgs as
openblasCompat.
[1]: https://wiki.debian.org/DebianScience/LinearAlgebraLibraries
[2]: https://wiki.gentoo.org/wiki/Blas-lapack-switch
hashed-mirrors are content addressed. So if $outputHash is in the
hashed-mirror, changes from ‘postFetch’ would already be made. So,
running postFetch will end up applying the change /again/, which we
don’t want.
I know, heretic, but...
I also know that this is not perfect but it is a good start, I think. It
would be nice if this were part of the automatic "nixdoc" function
reference. I'd like guidance if this should be part of the rust section
or something else.
"Application" is deprecated, "Other" is invalid, there are no generic
categories, and the Categories fields is optional per the spec.
Fixes the defaults after #75729.
Most of the skaware packages already build just fine with pkgsStatic,
however the wrapper scripts for execline and stdnotify-wrapper needed
the `-lskarlib` argument to go at the end.
`utmps` and `nsss` still fail with this error:
```
exec ./tools/install.sh -D -m 600 utmps-utmpd /bin/utmps-utmpd
/build/utmps-0.0.3.1/tools/install.sh: line 48: can't create /bin/utmps-utmpd.tmp.479: Permission denied
make: *** [Makefile:121: /bin/utmps-utmpd] Error 1
```
This reverts commit a50653295d.
The reasons cited were “debugging”, in which case
you can just add the attribute to `buildSkawarePackage`
and “customizing”, which is still possible with
a normal `overrideDerivation`.
The patch removed `outputs` for some reason
(possible oversight), so building nsss failed.
Plus lots of complexity (e.g. don’t forget to add new
arguments to `removeAttrs` otherwise there’s a bug now).
