- These symbols can be confusing for those not familiar with them
- There's no harm in making these more obvious
- Terminals may not print them correctly either
Also changes the function argument printing slightly to be more obvious
This new type has unsurprising merge behavior: Only attribute sets are
merged together (recursively), and only if they don't conflict.
This is in contrast to the existing types:
- types.attrs is problematic because later definitions completely
override attributes of earlier definitions, and it doesn't support
mkIf and co.
- types.unspecified is very similar to types.attrs, but it has smart
merging behavior that often doesn't make sense, and it doesn't support
all types
The vision here is that configuration tools can generate .json or .toml
files, which can be plugged into an existing configuration.
Eg:
{ lib, ... }:
{
imports = [
(lib.modules.importJSON ./hardware-configuration.json)
];
}
Jasper has been marked insecure for a while, and upstream has not
been responsive to CVEs for over a year.
Fixes#55388.
Signed-off-by: David Anderson <dave@natulte.net>
Previously the only way to deprecate a type was using
theType = lib.warn "deprecated" (mkOptionType ...)
This caused the warning to be emitted when the type was evaluated, but
the error didn't include which option actually used that type.
With this commit, types can specify a deprecationMessage, which when
non-null, is printed along with the option that uses the type
> NOTE: This function is not performant and should be avoided.
It's not used at all in-tree now, so we can remove it completely after
any remaining users are given notice.
An easy-to-make mistake when declaring e.g. a submodule is the accidental
confusion of `options` and `config`:
types.submodule {
config = {
foo = mkOption { /* ... */ };
};
}
However the error-message
The option `[definition 1-entry 1].foo' defined in `<expr.nix>' does not exist.
is fairly unhelpful because it seems as the options are declared at the
first sight. In fact, it took a colleague and me a while to track down such
a mistake a few days ago and we both agreed that this should be somehow caught
to save the time we spent debugging the module in question.
At first I decided to catch this error in the `submodules`-type directly
by checking whether `options` is undeclared, however this becomes fairly
complicated as soon as a submodule-declaration e.g. depends on existing
`config`-values which would've lead to some ugly `builtins.tryExec`-heuristic.
This patch now simply checks if the option's prefix has any options
defined if a point in evaluation is reached where it's clear that the
option in question doesn't exist. This means that this patch doesn't
change the logic of the module system, it only provides a more detailed
error in certain cases:
The option `[definition 1-entry 1].foo' defined in `<expr.nix>' does not exist.
However it seems as there are no options defined in [definition 1-entry 1]. Are you sure you've
declared your options properly? This happens if you e.g. declared your options in `types.submodule'
under `config' rather than `options'.
The refactoring in fd75dc8765
introduced a mistake in the error message that doesn't show the full
context anymore. E.g. with this module:
options.foo.bar = lib.mkOption {
type = lib.types.submodule {
baz = 10;
};
default = {};
};
You'd get the error
The option `baz' defined in `/home/infinisil/src/nixpkgs/config.nix' does not exist.
instead of the previous
The option `foo.bar.baz' defined in `/home/infinisil/src/nixpkgs/config.nix' does not exist.
This commit undoes this regression
Submodules that have a freeform type set behave as if that was the type
of the option itself (for values that don't have an option). Since the
submodules options are shown as separate entries in the manual, it makes
sense to show the freeform type as the submodule type.
For programs that have a lot of (Nix-representable) configuration options,
a simple way to represent this in a NixOS module is to declare an
option of a type like `attrsOf str`, representing a key-value mapping
which then gets generated into a config file. However with such a type,
there's no way to add type checking for only some key values.
On the other end of the spectrum, one can declare a single separate
option for every key value that the program supports, ending up with a module
with potentially 100s of options. This has the benefit that every value
gets type checked, catching mistakes at evaluation time already. However
the disadvantage is that the module becomes big, becomes coupled to the
program version and takes a lot of effort to write and maintain.
Previously there was a middle ground between these two
extremes: Declare an option of a type like `attrsOf str`, but declare
additional separate options for the values you wish to have type
checked, and assign their values to the `attrsOf str` option. While this
works decently, it has the problem of duplicated options, since now both
the additional options and the `attrsOf str` option can be used to set a
key value. This leads to confusion about what should happen if both are
set, which defaults should apply, and more.
Now with this change, a middle ground becomes available that solves above
problems: The module system now supports setting a freeform type, which
gets used for all definitions that don't have an associated option. This
means that you can now declare all options you wish to have type
checked, while for the rest a freeform type like `attrsOf str` can be
used.
This fundamentally changes how the module evaluation internally
handles definitions without an associated option.
Previously the values of these definitions were discarded and only
the names were propagated. This was fine because that's all that's
needed for optionally checking whether all definitions have an
associated option with _module.check.
However with the upcoming change of supporting freeform modules,
we *do* need the values of these.
With this change, the module evaluation cleanly separates definitions
that match an option, and ones that do not.
`toHex` converts the given positive integer to a string of the hexadecimal
representation of that integer. For example:
```
toHex 0 => "0"
toHex 16 => "10"
toHex 250 => "FA"
```
`toBase base i` converts the positive integer `i` to a list of it
digits in the given `base`. For example:
```
toBase 10 123 => [ 1 2 3 ]
toBase 2 6 => [ 1 1 0 ]
toBase 16 250 => [ 15 10 ]
```
The previous hash was too short and caused evaluation-time errors like:
invalid SRI hash 'sha256-AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA='
Additionally, since the fact that this is broken implies that nobody
could have been using it, "SRI" is a bit of a vague and obscure term,
`fakeSriHash` would be somewhat of a mouthful, and the relevant fetcher
parameters are just called `hash`, rename it to `fakeHash`.
This is used in in the manual generation for option identifiers that can
be linked. This, unike what the example describes, doesn't preserve
quotes which is needed for these identifiers to be valid.
This reverts commit 124cccbe3b.
124cccbe3b
broke the build of NixOS manual.
It does not make sense to be as strict as with attributes since we
are not limited by the CLI's inability to handle numbers.
Placeholders should not be quoted either as they are not part of Nix
syntax but a meta-level construct.
fix: Adding libtool to allow darwin compiles
Libtool seems to be required for mongodb to compile on darwin.
fix: Marking MongoDB as broken on aarch64
fix: Adding libtools to the pkg imports
Update mongodb to 4.0.4
Currently, not providing `name` to `cleanSourceWith` will use the name
of the imported directory. However, a common case is for this to be the
top level of some repository. In that case, the name will be the name of
the checkout on the current machine, which is not necessarily
reproducible across different settings, and can lead to e.g. cache
misses in CI.
This is documented in the comment on `cleanSourceWith`, but this does
not stop it being a subtle trap for users.
There are different tradeoffs in each case:
1. If `cleanSourceWith` defaults to `"source"`, then we may end up with a
user not knowing what directory a source store path corresponds to.
However, it being called "unnamed" may give them a clue that there is a
way for them to name it, and lead them to the definition of the
function, which has a clear `name` parameter.
2. If `cleanSoureWith` defaults to the directory name, then a user may face
occasional loss of caching, which is hard to notice, and hard to track
down. Tracking it down likely requires use of more advanced tools like
`nix-diff`, and reading the source of a lot of nix code.
I think the downside of the status quo is worse.
This is really another iteration of
https://github.com/NixOS/nix/issues/1305: that led to adding the `name`
argument in the first place, this just makes us use a better default
`name`.
The _module option is added as an internal option set, and it messes up
the results of module evaluations, requiring people to manually filter
_modules out.
If people depend on this, they can still use config._module from inside
the modules, exposing _module as an explicitly declared user option. Or
alternatively with the _module attribute now returned by evalModules.
newlib is the default for most tools when no kernel is provided. Other
exist, but this seems like a safe default.
(cherry picked from commit 8009c20711)
This helps with troubleshooting exceptions in config values, which were hard
to track down for options with many definitions.
The trace will look like:
error: while evaluating the attribute 'config.foo' at undefined position:
[...]
while evaluating the option `foo':
[...]
while evaluating definitions from `/home/user/mymod.nix':
while evaluating 'dischargeProperties' at /home/user/nixpkgs/lib/modules.nix:464:25, called from /home/user/nixpkgs/lib/modules.nix:392:137:
while evaluating the attribute 'value' at /home/user/nixpkgs/lib/modules.nix:277:44:
Value error!
where the `/home/user/mymod.nix` module is
{ lib, ... }: {
options.foo = lib.mkOption {
type = lib.types.lines;
};
config.foo = builtins.throw "Value error!";
}
In 87a19e9048 I merged staging-next into master using the GitHub gui as intended.
In ac241fb7a5 I merged master into staging-next for the next staging cycle, however, I accidentally pushed it to master.
Thinking this may cause trouble, I reverted it in 0be87c7979. This was however wrong, as it "removed" master.
This reverts commit 0be87c7979.
I merged master into staging-next but accidentally pushed it to master.
This should get us back to 87a19e9048.
This reverts commit ac241fb7a5, reversing
changes made to 76a439239e.
Let’s call them by what they are, option names.
`generators.mkValueStringDefault` is a better value string renderer
than plain `toString`.
Also add docs to all options.
The semantic difference between `encode` and `to` is not apparent.
Users are likely to confuse both functions (which leads to unexpected
error messages about the wrong types). Like in `generators.nix`, all
functions should be prefixed by `to`.
Furthermore, converting to a string depends on the target context. In
this case, it’s a POSIX shell, so we should name it that (compare
`escapeShellArg` in `strings.nix`).
We can later add versions that escape for embedding in e.g. python
scripts or similar.
lib/cli is very similar to generators, so it should follow largely the
same interface. Similar to how generators isn’t exported, we should
also namespace cli by default (plus “cli” is only three characters to
type).
Before c9214c394b and
9d396d2e42 if .git is symlink the version
would gracefully default to no git revision. With those changes an
exception is thrown instead.
This introduces a new function `pathIsGitRepo` that checks if
`commitIdFromGitRepo` fails without error so we don't have to
reimplement this logic again and can fail gracefully.
Not all modules use name attribute as the name of the submodule, for example,
environment.etc uses target. We will need to maintain a list of exceptions.
lib.commitIdFromGitRepo now resolves the refs from the
parent repository in case the supplied path is a file
containing the path to said repository. this adds support
for git-worktree and things alike. see gitrepository-layout(5).
this also:
- adds a new boolean function lib.pathIsRegularFile to
check whether a path is a regular file
- patches lib.revisionWithDefault and
the revision and versionSuffix attributes in
config.system.nixos in order to support git-worktrees
The standard attrsOf is strict in its *values*, meaning it's impossible to
access only one attribute value without evaluating all others as well.
lazyAttrsOf is a version that doesn't have that problem, at the expense
of conditional definitions not properly working anymore.
Without this change, accessing `mergedValue` from `mergeDefinitions` in
case there are no definitions will throw an error like
error: evaluation aborted with the following error message: 'This case should never happen.'
This change makes it throw the appropriate error
error: The option `foo' is used but not defined.
This is fully backwards compatible.
Fix the broken test in https://github.com/NixOS/nixpkgs/pull/77416
Apparently hydra uses `nix-build lib/tests/release.nix` to run all
tests, where IFD isn't allowed. Fortunately we can get around this with
builtins.toFile, which doesn't require IFD, but still can test the
properties we want.
This fixes imports from the store not being possible, which was caused by
https://github.com/NixOS/nixpkgs/pull/76857
E.g. such a case:
imports = [ "${home-manager}/nixos" ];
With this change, disabledModules applies recursively, meaning if you
have a module "foo.nix" with
imports = [ ./bar.nix ];
then setting
disabledModules = [ "foo.nix" ];
will disable both "foo.nix" and "bar.nix", whereas previously only
"foo.nix" would be disabled.
This change along with https://github.com/NixOS/nixpkgs/pull/61570 allows
modules to be fully disabled even when they have some `mkRenamedOption`
imports.
Previously when this function was called without a value coercible to a
string it would throw an error instead of returning false. Now it does.
As a result this now allows the use of a type like `either path attrs`
without it erroring out when a definition is an attribute set.
The warning about there not being a isPath primop was removed because
this is not the case anymore, there is builtins.isPath. But also there
always was `builtins.typeOf x == "path"` that could've been used
instead. However the path type now stands for more than just path types,
but absolute paths in general.
If I understand correctly, the problem isn't so much that you're assigning to
that top-level attribute, but that the assignment to the attribute (or any
child of the attribute) introduces the 'config' object and prevents 'lifting'
all settings to a generated 'config' object.
This reverts commit eec83d41e3.
This broke hydra evaluation because with this commit submodule values
are allowed to be paths, however the certmgr module uses `either
(submodule ...) path` in its type, meaning it already used paths for
something else which would now be interpreted as a submodule.
This adds a new utility to intelligently convert Nix records to
command line options to reduce boilerplate for simple use cases and to
also reduce the likelihood of malformed command lines
`pipe` is a useful operator for creating pipelines of functions.
It works around the usual problem of e.g. string operations becoming
deeply nested functions.
In principle, there are four different ways this function could be
written:
pipe val [ f1 .. fn ]
pipe val [ fn .. f1 ]
compose [ f1 .. fn ] val
compose [ fn .. f1 ] val
The third and fourth form mirror composition of functions, they would
be the same as e.g. `(f1 << f2 << f3 .. << fn) val`.
However, it is not clear which direction the list should have (as one
can see in the second form, which is the most absurd.
In order not to confuse users, we decide for the most “intuitive”
form, which mirrors the way unix pipes work (thus the name `pipe`).
The flow of data goes from left to right.
Co-Authored-By: Silvan Mosberger <infinisil@icloud.com>
Remove the "version" parameter in order to make it more widely
available.
Starts making some kernel configuration helpers available.
The intent is to be able to better build and check the linux kernel
configuration.
We don't want to ignore config that can mess up machines. In general
this should always fail evaluation, as you think you are changing
behaviour and don't, which can easily create run-time errors we can
catch early.
Previously mkRemovedOptionModule would only show the replacement
instructions when the removed option was *defined*. With this change, it
also does so when an option is *used*.
This is essential for options that are only intended to be used such as
`security.acme.directory`, whose replacement instructions would never
trigger without this change because almost everybody only uses the
option and isn't defining it.
This makes the function available without having to evaluate the
Nixpkgs fix-point, making it available in a more natural way for
code that deals with multiple Nixpkgs invocations.
Its definition is coupled to Nix rather than Nixpkgs, so it will
feel right at home in lib.
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)
```
Comments on conflicts:
- llvm: d6f401e1 vs. 469ecc70 - docs for 6 and 7 say the default is
to build all targets, so we should be fine
- some pypi hashes: they were equivalent, just base16 vs. base32
This should make the composability of kernel configurations more straigthforward.
- now distinguish freeform options from tristate ones
- will look for a structured config in kernelPatches too
one can now access the structuredConfig from a kernel via linux_test.configfile.structuredConfig
in order to reinject it into another kernel, no need to rewrite the config from scratch
The following merge strategies are used in case of conflict:
-- freeform items must be equal or they conflict (mergeEqualOption)
-- for tristate (y/m/n) entries, I use the mergeAnswer strategy which takes the best available value, "best" being defined by the user (by default "y" > "m" > "n", e.g. if one entry is both marked "y" and "n", "y" wins)
-- if one item is both marked optional/mandatory, mandatory wins (mergeFalseByDefault)
This commit changes the `mkAliasOptionModule` function to make sure that
the priority for the aliased option is propagated to the non-aliased
option.
This also affects the `mkRenamedOptionModule` function in a similar
fashion.
This also removes the `mkAliasOptionModuleWithPriority` function, since
its functionality is now subsumed by `mkAliasOptionModule`.
This change was recommended by @nbp:
https://github.com/NixOS/nixpkgs/pull/53397#discussion_r245487432
Fake hashes can be used as placeholders for all the places, where
Nix expression requires a hash, but we don't yet have one.
This should be more convenient than following:
- echo|sha256sum, copy into clipboard, go to editor, paste into previously
edited place
- search nixpkgs for a random package, copy it's hash to cliboard, go to
editor, paste into previously edited place
Nix can add support for these fake hashes. In that case printed error should contain
only 1 hash, so no more problem "which of two hashes from error should I use?"
Idea by irc:Synthetica
* add generic x86_32 support
- Add support for i386-i586.
- Add `isx86_32` predicate that can replace most uses of `isi686`.
- `isi686` is reinterpreted to mean "exactly i686 arch, and not say i585 or i386".
- This branch was used to build working i586 kernel running on i586 hardware.
* revert `isi[345]86`, remove dead code
- Remove changes to dead code in `doubles.nix` and `for-meta.nix`.
- Remove `isi[345]86` predicates since other cpu families don't have specific model predicates.
* remove i386-linux since linux not supported on that cpu
This commit adds a function `mkAliasOptionModuleWithPriority`. This
function will make an alias to an existing option and copy over the
priority.
This functionality is needed for PRs like #53041. In that case
`nixos-generate-config` added an option to `hardware-configuration.nix`
with `mkDefault`. That option was then changed and an alias created for
the old name.
The end user should be able to set the non-alias option in their
`configuration.nix` and have everything work correctly. Without this
function, the priority for the option won't be copied over correctly
and the end-user will get a message saying they have the same option
set to two different values.
See the bottom of https://spdx.org/licenses/ for the list of deprecations.
The explicit URLs of agpl3Plus and gpl2Classpath were dropped because the
default SPDX URL is correct.
wxWindows ID had wrong capitalization.
Suppose I have a Gemfile like this:
source "https://rubygems.org"
gem "actioncable"
gem "websocket-driver", group: :test
The gemset.nix generated by Bundix 2.4.1 will set ActionCable's groups
to [ "default" ], and websocket-driver's to [ "test" ]. This means that
the generated bundlerEnv wouldn't include websocket-driver unless the
test group was included, even though it's required by the default group.
This is arguably a bug in Bundix (websocket-driver's groups should
probably be [ "default" "test" ] or just [ "default" ]), but there's no
reason bundlerEnv should omit dependencies even given such an input --
it won't necessarily come from Bundix, and it would be good for
bundlerEnv to do the right thing.
To fix this, filterGemset is now a recursive function, that adds
dependencies of gems in the group to the filtered gemset until it
stabilises on the gems that match the required groups, and all of their
recursive dependencies.
eabihf is an abi that can be used with ARM architectures that support
the “hard float”. It should probably only be used with ARM32 when you
are absolutely sure your binaries will run on ARM systems with a FPU.
Also, add an example "armhf-embedded" to match the preexisting
arm-embedded system. qmk_firmware needs hard float in a few places, so
add them here to get that to work.
Fixes#51184
You can use stdenv.hostPlatform.emulator to get an executable that
runs cross-built binaries. This could be any emulator. For instance,
we use QEMU to emulate Linux targets and Wine to emulate Windows
targets. To work with qemu, we need to support custom targets.
I’ve reworked the cross tests in pkgs/test/cross to use this
functionality.
Also, I’ve used talloc to cross-execute with the emulator. There
appears to be a cross-execute for all waf builds. In the future, it
would be nice to set this for all waf builds.
Adds stdenv.hostPlatform.qemuArch attrbute to get the qemuArch for
each platform.
AMD license agreement (currently unavailable at the given URL, but
included in tarball) disallows reverse-engineering, modification,
redistribution etc;
BSL licenses limit commercial production use.
- respect libc’s incdir and libdir
- make non-unix systems single threaded
- set LIMITS_H_TEST to false for avr
- misc updates to support new libc’s
- use multilib with avr
For threads we want to use:
- posix on unix systems
- win32 on windows
- single on everything else
For avr:
- add library directories for avrlibc
- to disable relro and bind
- avr5 should have precedence over avr3 - otherwise gcc uses the wrong one
Documents functions in `lib.options` for docs generation with nixdoc.
The formatting change in the `mkOption` arguments is due to the way
`nixdoc` parses documentation comments on pattern arguments. It's not
ideal, but it works.
Documents functions in `lib.debug` for docs generation with nixdoc.
Note that type signatures and clearer descriptions are still missing
on some of these functions, but this is good enough for a first run.
Updates documentation comments with extra information for nixdoc[1]
compatibility.
Some documentation strings have additionally been reworded for
clarity.
"Faux types" are added where applicable, but some functions do things
that are not trivially representable in the type notation used so they
were ignored for this purpose.
[1]: https://github.com/tazjin/nixdoc
This reverts commit 10addad603, reversing
changes made to 7786575c6c.
NixOS scripts should be kept in the NixOS source tree, not in
pkgs. Moving them around is just confusing and creates unnecessary
code/history churn.
The previous description "string" is misleading in the full options
manual pages; they are actually concatenated strings, with a specific
character.
The empty string version ("types.string") has been special-cased to
provide a better message.
The `overrideScope` bound by `makeScope` (via special `callPackage`)
took an override in the form `super: self { … }`. But this is
dangerously close to the `self: super { … }` form used by *everything*
else, even other definitions of `overrideScope`! Since that
implementation did not even share any code either until I changed it
recently in 3cf43547f4, this inconsistency
is almost certainly an oversight and not intentional.
Unfortunately, just as the inconstency is hard to debug if one just
assumes the conventional order, any sudden fix would break existing
overrides in the same hard-to-debug way. So instead of changing the
definition a new `overrideScope'` with the conventional order is added,
and old `overrideScope` deprecated with a warning saying to use
`overrideScope'` instead. That will hopefully get people to stop using
`overrideScope`, freeing our hand to change or remove it in the future.
This packags the Intel Math Kernel library on x86-64 platforms, which is a
dependency for many data science and machine learning packages.
Upstream, Intel provides proprietary binary RPMs with a permissive
redistribution license. These have been repackaged in both Debian and Anaconda,
so we are not the first distribution to redistribute.
The original build broke with the following linker issue:
```
CXXLD _PythonMagick.la
/nix/store/h0lbngpv6ln56hjj59i6l77vxq25flbz-binutils-2.30/bin/ld: cannot find -l-L/nix/store/4gh6ynzsd5ndx37hmkl62xa8z30k43y1-imagemagick-6.9.9-34/lib
collect2: error: ld returned 1 exit status
```
This happens since `BOOST_PYTHON_LIB` wasn't set properly, however
`_PythonMagick.la` was linked with `-l$(BOOST_PYTHON_LIB)
$(MAGICK_LIBS)`. With an empty `BOOST_PYTHON_LIB` the linker got
confused.
To work around this, the `boost` library directory needs to be specified
explicitly. To ensure that the changes take effect, the original
`configure` script shipped with `$src` needs to be removed and recreated
using the `autoreconfHook`.
Additionally the `imagemagick` license (https://spdx.org/licenses/ImageMagick.html)
needs to be added to `lib/licenses.nix` to document the proper license
of `pythonmagick` in the meta section.
This has been not touched in 6 years. Let's remove it to cause less
problems when adding new cross-compiling infrastructure.
This also simplify gcc significantly.
- moved function into strings.nix
- renamed function from makePerl5Lib
- removed duplicates entries in the resulting value
- rewrote the function from scratch after learning a few things (much cleaner now)
Another attempt after my sloppy 48ccdf322d.
@Infinisil, thanks again, reverted in 4794aa5de2 and explained my mistakes in 48ccdf322d (commitcomment-29678643). I start with their work and provide this proof of this commit's correctness:
```nix
(lib.fixedPoints.extends (lib.flip g) f) # now
((f: rattrs: self: let super = rattrs self; in super // f self super) (lib.flip g) f) # inline extends
(self: let super = f self; in super // (lib.flip g) self super) # beta reduce
(self: let super = f self; in super // g super self) # beta reduce
(self_: let super = f self_; in super // g super self_) # alpha rename
(self_: let super = f self_; in super // g super self_) # original, same
```
Eventually we might harmonize `overrideScope`'s `g` parameter with the general pattern, but I leave that breaking change as a separate step. Best not to refactor and break at once, and at least the abstractions make the oddity clearer.
