This allows querying function arguments of things like fetchFromGitHub:
nix-repl> lib.functionArgs pkgs.fetchFromGitHub
{ fetchSubmodules = true; githubBase = true; ... }
This change is API-compatible and hash-compatible with the previous
version.
At first I considered to write a rename function too, but adding
it name to cleanSourceWith was a no-brainer for ease of use. It
turns out that a rename function isn't any more useful than
cleanSourceWith.
To avoid having to write the identity predicate when renaming,
the filter is now optional.
builtins.path is supported since Nix 2.0 which is required by nixpkgs
This allows `apply` functions to return a valid value if they completely
ignore their argument, which is the case for the option renaming
functions like `mkAliasOptionModule`. Therefore this solves issue #63693
`sourceByRegex src regexes` should include a source file if one of the
regular expressions `regexes` matches the path of that file relative
to `src`.
However to compute this relative path `sourceByRegex` uses:
```
relPath = lib.removePrefix (toString src + "/") (toString path);
```
Note that `toString path` evaluates to an absolute file somewhere
under `src` and not under `/nix/store`.
The problem is that this doesn't work if `src` is a `cleanSourceWith`
invocation as well because `toString src` will then evaluate to
`src.outPath` which will evaluate to `builtins.filterSource ...` which
evaluates to a path in `/nix/store` which is not a prefix of `path`.
The solution is to replace `src` with `origSrc` where
```
origSrc = if isFiltered then src.origSrc else src;
isFiltered = src ? _isLibCleanSourceWith;
```
Test this by executing the following from the nixpkgs repo:
```
(cat << 'EOI'
let
pkgs = import ./. {};
in pkgs.runCommand "test-sourceByRegex" {
test_sourceByRegex =
let
src1 = pkgs.lib.sourceByRegex ./. [ "^test-sourceByRegex.nix$" ];
src2 = pkgs.lib.sourceByRegex src1 [ "^test-sourceByRegex.nix$" ];
in src2 + "/test-sourceByRegex.nix";
} ''
cp $test_sourceByRegex $out
''
EOI
) > test-sourceByRegex.nix
nix-build test-sourceByRegex.nix
```
The main purpose is to bring attention to `flip map`, which improves
code readablity. It is useful when ad-hoc anonymous function
grows two or more lines in `map` application:
```
map (lcfg:
let port = lcfg.port;
portStr = if port != defaultPort then ":${toString port}" else "";
scheme = if cfg.enableSSL then "https" else "http";
in "${scheme}://cfg.hostName${portStr}"
) (getListen cfg);
```
Compare this to `foreach`-style:
```
foreach (getListen cfg) (lcfg:
let port = lcfg.port;
portStr = if port != defaultPort then ":${toString port}" else "";
scheme = if cfg.enableSSL then "https" else "http";
in "${scheme}://cfg.hostName${portStr}"
);
```
This is similar to Haskell's `for` (http://hackage.haskell.org/package/base-4.12.0.0/docs/Data-Traversable.html#v:for)
This reverts commit ce2f74df2c.
Doubles are treated as -darwin here, to provide some consistency.
There is some ambiguity between “x86_64-darwin” and “i686-darwin”
which could refer to binaries linked between iOS simulator or real
macOS binaries. useiOSPrebuilt can be used to determine which to use,
however.
The error can be reproduced like:
```
$ nix-instantiate ./nixos -A system --arg configuration '
{ fileSystems."/".device = "nodev";
boot.loader.grub.devices = [ "nodev" ];
containers.t.config.imports = [ <nixpkgs/nixos/modules/virtualisation/amazon-image.nix> ];
}'
```
Previously error was:
```
error: The unique option `containers.t.networking.hostName' is defined multiple times, in `/nix/var/nix/profiles/per-user/root/channels/nixpkgs/nixos/modules/virtualisation/amazon-image.nix' and `module at /home/danbst/dev/nixpkgs/nixos/modules/virtualisation/containers.nix:470'.
(use '--show-trace' to show detailed location information)
```
Now it is:
```
error: The unique option `containers.t.networking.hostName' is defined multiple times, in:
- /nix/var/nix/profiles/per-user/root/channels/nixpkgs/nixos/modules/virtualisation/amazon-image.nix
- module at /home/danbst/dev/nixpkgs/nixos/modules/virtualisation/containers.nix:470.
(use '--show-trace' to show detailed location information)
```
Related: https://github.com/NixOS/nixpkgs/issues/15747
This makes things a little bit more convenient. Just pass in like:
$ nix-build ’<nixpkgs>’ -A hello --argstr localSystem x86_64-linux --argstr crossSystem aarch64-linux
Adds pkgsCross.wasm32 and pkgsCross.wasm64. Use it to build Nixpkgs
with a WebAssembly toolchain.
stdenv/cross: use static overlay on isWasm
isWasm doesn’t make sense dynamically linked.
It is useful to make these dynamic and not bake them into gcc. This
means we don’t have to rebuild gcc to change these values. Instead, we
will pass cflags to gcc based on platform values. This was already
done hackily for android gcc (which is multi-target), but not for our
own gccs which are single target.
To accomplish this, we need to add a few things:
- add ‘arch’ to cpu
- add NIX_CFLAGS_COMPILE_BEFORE flag (goes before args)
- set -march everywhere
- set mcpu, mfpu, mmode, and mtune based on targetPlatform.gcc flags
cc-wrapper: only set -march when it is in the cpu type
Some architectures don’t have a good mapping of -march. For instance
POWER architecture doesn’t support the -march flag at all!
https://gcc.gnu.org/onlinedocs/gcc/RS_002f6000-and-PowerPC-Options.html#RS_002f6000-and-PowerPC-Options
This makes us less reliant on the systems/examples.nix. You should be
able to cross compile with just your triple:
$ nix build --arg crossSystem '{ config = "armv6l-unknown-linux-gnueabi"; }' stdenv
ppc64le and ppc64 are different targets in the configure script. We
can’t use the same one.
TODO: canonicalize similar ones based on qemu’s configure script.
New android ndk (18) now uses clang. We were going through the wrapper
that are provided. This lead to surprising errors when building.
Ideally we could use the llvm linker as well, but this leads to errors
as many packages don’t support the llvm linker.
The explicit remove helped to uncover some hidden uses of `optionSet`
in NixOps. However it makes life harder for end-users of NixOps - it will
be impossible to deploy 19.03 systems with old NixOps, but there is no
new release of NixOps with `optionSet` fixes.
Also, "deprecation" process isn't well defined. Even that `optionSet` was
declared "deprecated" for many years, it was never announced. Hence, I
leave "deprecation" announce. Then, 3 releases after announce,
we can announce removal of this feature.
This type has to be removed, not `throw`-ed in runtime, because it makes
some perfectly fine code to fail. For example:
```
$ nix-instantiate --eval -E '(import <nixpkgs/lib>).types' --strict
trace: `types.list` is deprecated; use `types.listOf` instead
error: types.optionSet is deprecated; use types.submodule instead
(use '--show-trace' to show detailed location information)
```
