There are two different official variations which differ in their float
support, so such a blanket statement is invalid.
`lib.systems.platforms.*android` already handles each case correctly.
Correcting an error in 827ef09140.
ARM ABIs now have a float field. This is used as a fallback to lessen
our use of `platform.gcc.float`. I didn't know what the MIPs convention
is so I kept using `platform.gcc.float` in that case.
Assigning a list of 10 or more elements to an option having the type
`loaOf a` produces a configuration value that is not honoring the
order of the original list. This commit fixes this and a related issue
arising when 10 or more lists are merged into this type of option.
Without this change
(coercedTo str toInt int).check "foo"
would evaluate to true, even though
(coercedTo str toInt int).merge {} [{ value = "foo"; }]
will throw an error because "foo" can't be coerced to an int.
The commented-out configs are @shlevy's old known-good ones. I changed
them as needed to play nice with lib.systems.parse but did not test so
leaving them as comments for now.
As suggested in https://github.com/NixOS/nixpkgs/pull/39416#discussion_r183845745
the versioning attributes in `lib` should be consistent to
`nixos/version` which implicates the following changes:
* `lib.trivial.version` -> `lib.trivial.release`
* `lib.trivial.suffix` -> `lib.trivial.versionSuffix`
* `lib.nixpkgsVersion` -> `lib.version`
As `lib.nixpkgsVersion` is referenced several times in `NixOS/nixpkgs`,
`NixOS/nix` and probably several user's setups. As the rename will cause
a notable impact it's better to keep `lib.nixpkgsVersion` as alias with
a warning yielded by `builtins.trace`.
The function isn’t used anywhere and `addErrorContext` is an undocumented
builtin.
The builtin is explicitely qualified at its two uses in the module system.
`attrNamesToStr` is very specific (and pretty trivial), so it doesn’t make sense
to have it in the library.
`traceXMLVal(Marked)` are just a builtin and `trace` and not very useful in
general (trace output should not be parsed anyway).
Following legacy packing conventions, `isArm` was defined just for
32-bit ARM instruction set. This is confusing to non packagers though,
because Aarch64 is an ARM instruction set.
The official ARM overview for ARMv8[1] is surprisingly not confusing,
given the overall state of affairs for ARM naming conventions, and
offers us a solution. It divides the nomenclature into three levels:
```
ISA: ARMv8 {-A, -R, -M}
/ \
Mode: Aarch32 Aarch64
| / \
Encoding: A64 A32 T32
```
At the top is the overall v8 instruction set archicture. Second are the
two modes, defined by bitwidth but differing in other semantics too, and
buttom are the encodings, (hopefully?) isomorphic if they encode the
same mode.
The 32 bit encodings are mostly backwards compatible with previous
non-Thumb and Thumb encodings, and if so we can pun the mode names to
instead mean "sets of compatable or isomorphic encodings", and then
voilà we have nice names for 32-bit and 64-bit arm instruction sets
which do not use the word ARM so as to not confused either laymen or
experienced ARM packages.
[1]: https://developer.arm.com/products/architecture/a-profile
(cherry picked from commit ba52ae5048)
Following legacy packing conventions, `isArm` was defined just for
32-bit ARM instruction set. This is confusing to non packagers though,
because Aarch64 is an ARM instruction set.
The official ARM overview for ARMv8[1] is surprisingly not confusing,
given the overall state of affairs for ARM naming conventions, and
offers us a solution. It divides the nomenclature into three levels:
```
ISA: ARMv8 {-A, -R, -M}
/ \
Mode: Aarch32 Aarch64
| / \
Encoding: A64 A32 T32
```
At the top is the overall v8 instruction set archicture. Second are the
two modes, defined by bitwidth but differing in other semantics too, and
buttom are the encodings, (hopefully?) isomorphic if they encode the
same mode.
The 32 bit encodings are mostly backwards compatible with previous
non-Thumb and Thumb encodings, and if so we can pun the mode names to
instead mean "sets of compatable or isomorphic encodings", and then
voilà we have nice names for 32-bit and 64-bit arm instruction sets
which do not use the word ARM so as to not confused either laymen or
experienced ARM packages.
[1]: https://developer.arm.com/products/architecture/a-profile
This allows the lib fixed point to be extended with
myLib = lib.extend (self: super: {
foo = "foo";
})
With this it's possible to have the new modified lib attrset available to all
modules when using evalModules
myLib.evalModules {
modules = [ ({ lib, ... }: {
options.bar = lib.mkOption {
default = lib.foo;
};
}) ];
}
=> { config = { bar = "foo"; ... }; options = ...; }
- `localSystem` is added, it strictly supercedes system
- `crossSystem`'s description mentions `localSystem` (and vice versa).
- No more weird special casing I don't even understand
TEMP
So far, `mkValueString` defaulted to `toString`,
which is a bad match for most configuration file formats,
especially because how booleans are formatted.
This also improves error messages for unsupported types.
Add a test to codify the formatting.
The isSeccomputable flag treated Linux without seccomp as just a
normal variant, when it really should be treated as a special case
incurring complexity debt to support.
The isKexecable flag treated Linux without kexec as just a normal
variant, when it really should be treated as a special case incurring
complexity debt to support.
Uses the HTTPS url for cases where the existing URL has a permanent
redirect. For each domain, at least one fixed derivation URL was
downloaded to test the domain is properly serving downloads.
Also fixes jbake source URL, which was broken.
Otherwise obscure cross-compilations are hampered. `all` breaks all but
the initial derivation (which we can't even write yet) in an open world
setting however, so we really shouldn't have it.
I noticed LLVM accepts `ios` as its own OS in platform triples; a
recent change as far as I know. I see it also accepts `macos*` for macOS
(formerly OS X). If it's now customary to distinguish iOS like so
(rather than guessing from the aarch, lets add both so our OSes are
still disjoint, and make Darwin a family instead.
But changing the config everywhere would probably be a mass rebuild, and
I'm not sure how well other software supports OSes besides "darwin", so
I'm keeping that the default name for macOS for now.
First, we need check against the host platform, not the build platform.
That's simple enough.
Second, we move away from exahustive finite case analysis (i.e.
exhaustively listing all platforms the package builds on). That only
work in a closed-world setting, where we know all platforms we might
build one. But with cross compilation, we may be building for arbitrary
platforms, So we need fancier filters. This is the closed world to open
world change.
The solution is instead of having a list of systems (strings in the form
"foo-bar"), we have a list of of systems or "patterns", i.e. attributes
that partially match the output of the parsers in `lib.systems.parse`.
The "check meta" logic treats the systems strings as an exact whitelist
just as before, but treats the patterns as a fuzzy whitelist,
intersecting the actual `hostPlatform` with the pattern and then
checking for equality. (This is done using `matchAttrs`).
The default convenience lists for `meta.platforms` are now changed to be
lists of patterns (usually a single pattern) in
`lib/systems/for-meta.nix` for maximum flexibility under this new
system.
Fixes#30902
Negative reasoning like `allBut` is a bad idea with an open world of
platforms. Concretely, if we add a new, quite different sort of
platform, existing packages with `allBut` will claim they work on it
even though they probably won't.
