All other functions are in the form of `*{c,C}heckpointBuild*`, so we
deprecate the `mkCheckpointedBuild` function in favor of `mkCheckpointBuild`.
Also address some inconsistencies in the docs: some `buildOutput` should
actually be `incrementalBuildArtifacts`.
The build log of the following won't output `foo` as one might expect, but the
`$PATH` set by stdenv.
```nix
with import <nixpkgs> {};
runCommand "foo" { PATH = "foo"; } "echo $PATH; touch $out"
```
- It's useless. The correct attribute name would be `license` and not
`licenses`. Meaning setting this never did anything useful.
- It used IFD in its implementation, meaning to know what the licenses
of a nuget source are, you first had to build that nuget source. This
defeats the point of having license checks in the first place.
- IFD is not allowed by the nixpkgs CI and build farm anyway.
Without the change metadata evaluation fails on package like
`zammad.src` where no fields are defined in `.nix `files:
src = fetchFromGitHub (lib.importJSON ./source.json);
There evaluation fails as:
$ nix-instantiate --strict --eval --expr 'with import ./. {}; zammad.src.meta'
error:
23| # to indicate where derivation originates, similar to make-derivation.nix's mkDerivation
24| position = "${position.file}:${toString position.line}";
| ^
25| };
error: value is null while a set was expected
After the change evaluation succeeds as:
$ nix-instantiate --strict --eval --expr 'with import ./. {}; zammad.src.meta'
{ homepage = "https://github.com/zammad/zammad"; }
Before the change there was no way to poll for presence of
`vendorSha256` attribute:
$ nix-instantiate --strict --eval --expr 'with import ./. {}; _3mux.vendorSha256 or "no hash"'
error: attribute 'vendorSha256' missing
292| passthru = passthru // { inherit go goModules vendorHash; } // { inherit (args') vendorSha256; };
| ^
After the change the poll happens as expected:
$ nix-instantiate --strict --eval --expr 'with import ./. {}; _3mux.vendorSha256 or "no hash"'
"no hash"
- Remove superflous `let` with `defaultMeta`
These can just be assigned to meta directly instead.
- Hoist internal intermediate derivation
- Remove top-level `with lib`
- Inherit `lib`/`builtins` into scopes
We now use a newer version of package-build, since
previously-necessary functions have been moved/removed from package.el
Emacs 30. See https://github.com/melpa/package-build/pull/87
Consequently, some changes are necessary to the corresponding patch
and to melpa2nix.el, which this commit also contains.
We get a dependency list with pub2nix now. We can no longer easily distinguish between development dependency dependencies and regular dependency dependencies, but we weren't doing this anyway.
Conflicts:
- pkgs/development/python-modules/boto3-stubs/default.nix
- pkgs/development/python-modules/openllm-core/default.nix
Between 0.4.22 → 0.4.34 (a82245bd3d)
and 0.4.22 -> 0.4.41 (72c55ce6a6)
Does not build, not pre-merge either.
Prior to this change, the `importCargoLock` git dependency builder
assumed that the workspace root that needed to be passed to
`replace-workspace-values` will always be the root directory of the git
repository.
This is not always the case as independent workspace roots may be used
from subdirectories, and packages be referenced via paths. An example of
this is [1], where the `iced` subdirectory is its own independent
workspace, and workspace values for packages within it should be pulled
from the `iced` subdirectory as the workspace root, not from the
top-level of the fetched repository.
[1]: b8f1a366dd/Cargo.toml
With `cargoRoot` set to a subdirectory of the source, where the
Cargo.{lock,toml} are found, the final mv would previously fail, since
the build results appear relative to cargoRoot, not to the original
build directory.
It turns out that unlike a normal Unix program, if the --sysroot
option is given more than once, rustc will error rather than using the
last value given. Therefore, we need to ensure we only add our
default --sysroot argument if one hasn't been given explicitly on the
wrapper's command line.
This fixes cross compilation of rustc.
Closes: https://github.com/NixOS/nixpkgs/issues/271736
Fixes: 8b51cdd3be ("rustc: add a compiler wrapper")
Rust 1.74 added support for configuring lints with cargo in a new
"lints" table. This also adds a new possible position to reference the
host workspace.
Fixes#273835
This function is not, and never have been, used anywhere inside nixpkgs, outside of bootstrapping setupcfg2nix itself.
It was added in https://github.com/NixOS/nixpkgs/pull/38778 by @shlevy.
It has no out-of-tree users on Github either. External breakage is not expected.
this makes it a lot easier to create a modified stdenv with a
different set of defaultHardeningFlags and as a bonus allows us
to inject the correct defaultHardeningFlags into toolchain wrapper
scripts, reducing repetition.
while most hardening flags are arguably more of a compiler thing,
it works better to put them in bintools-wrapper because cc-wrapper
can easily refer to bintools but not vice-versa.
mkDerivation can still easily refer to either when it is constructed.
this also switches fortran-hook.sh to use the same defaults for
NIX_HARDENING_ENABLE as for C. previously NIX_HARDENING_ENABLE
defaults were apparently used to avoid passing problematic flags
to a fortran compiler, but this falls apart as soon as mkDerivation
sets its own NIX_HARDENING_ENABLE - cc.hardeningUnsupportedFlags
is a more appropriate mechanism for this as it actively filters
out flags from being used by the wrapper, so switch to using that
instead.
this is still an imperfect mechanism because it doesn't handle a
compiler which has both langFortran *and* langC very well - applying
the superset of the two's hardeningUnsupportedFlags to either
compiler's invocation. however this is nothing new - cc-wrapper
already poorly handles a langFortran+langC compiler, applying two
setup hooks that have contradictory options.
Please Nix CI (OfBorg) with empty set instead of null on non-linux platforms,
where NixOS tests are not supported.
Co-authored-by: Robert Hensing <roberth@users.noreply.github.com>
Define package `testScriptBin` that contains the substituted test script.
* Add an `installCheckPhase` to check the result script with ShellCheck.
* Passthru as `references.testScriptBin` to run the
(substituted) test script directly (without VM).
* Drop the logic in build script that detects if
it is run in the Nix sandbox.
* Inline sample application; drop invoke-*.nix.
Format expressions.
* Format with `nixpkgs-fmt`.
* Use multi-line style of set patterns.
Call the samples with `callPackage`.
* Rename `sample` -> `samples`.
* Take individual packages / build helpers directly from the
set pattern.
* Define `cleanSamples` to filter out overriders such as `<pkg>.override`.
added by `callPackage`.
Passthru samples and invocation results for easier debugging.
* Passthru samples, references, directReferences
* Provide tests.trivial-builders.writeStringReferencesToFile with such
samples argument.
After #268458, when setting `enableFakechroot = true` and
`includeStorePaths = false`, some of the store paths were getting
included into the image anyway, thru `bind-paths`.
This resulted in unexpectedly large images.
Now, the images will not contain any store paths under those
circumstances.
Fixed conflict in pkgs/applications/graphics/krita/
krita: 5.1.5 -> 5.2.0
7a40fdc288
, and
treewide: use kde mirror everywhere, don't use pname in download urls
aa15f5066d
The previous find invocation didn't match the root directory, so the
root directory's access and modification time wasn't set to a
deterministic value and the build time leaked into the output.
`make-initrd` replaced `cpio` with `bsdtar` in #165892 because the
former includes the number of hardlinks in the created archive, which
depends on the filesystem (and can also be influenced by `nix-store
--optimise`). The same problem applies to `make-initrd-ng`, so this
commit replaces `cpio` with `libarchive`'s `bsdtar`.
-B must be set to the root directory of avrlibc, otherwise gcc cannot
locate crt objects for some attiny devices. -L trains as set by
bintools-wrapper are not necessary with -B set correctly because gcc
takes care of that, and likewise we can drop the -B train from
cc-wrapper because the one spec is enough.
Setting RUSTFLAGS causes Cargo to ignore other ways of configuring
flags, including the target-specific RUSTFLAGS options. This broke
pkgsCross.musl64.crosvm, and was surprising to users.
Fixes: https://github.com/NixOS/nixpkgs/pull/261727
We keep running into situations where we can't get the right
combination of rustc flags through build systems into rustc.
RUSTFLAGS is the only variable supported across build systems, but if
RUSTFLAGS is set, Cargo will ignore all other ways of specifying rustc
flags, including the target-specific ones, which we need to make
dynamic musl builds work. (This is why pkgsCross.musl64.crosvm is
currently broken — it works if you unset separateDebugInfo, which
causes RUSTFLAGS not to be set.)
So, we need to do the same thing we do for C and C++ compilers, and
add a compiler wrapper so we can inject the flags we need, regardless
of the build system.
Currently the wrapper only supports a single mechanism for injecting
flags — the NIX_RUSTFLAGS environment variable. As time goes on,
we'll probably want to add additional features, like target-specific
environment variables.
A handful of kernel modules use glob patterns to express their
firmware dependencies. (`git grep 'MODULE_FIRMWARE.*\*'`)
Previously, we weren't handling these patterns. Now, we are.
