`For android 'sdkVer' has been renamed to 'androidSdkVersion'`
While doing the above rename I forgot to consider if there were still
darwin platforms in `lib.systems.examples` using `sdkVer`
These still fail eval, but that happened before the renaming too.
`error: Unsupported sdk: 14.3`
Mesa is a package like any other. There's no reason for it to be a
special case with its platforms listed in lib, because if other
packages want to refer to mesa's platforms, they can access the
platforms from the package meta like they would for any other package.
Those attrs have been renamed and throwing is the best way to show it,
if we only warned then the user would only get an error like this `error: Unsupported sdk: 33`
from `pkgs/top-level/darwin-packages.nix`.
If someone wants to support multiple NixOS versions then they can simply
set both attrs. (`!args ? androidSdkVersion` is for that)
`sdkVer` conflicts with the old `sdkVer`(now `darwinSdkVersion` but that still uses `sdkVer` if set) used by darwin
This shouldn't be an issue but due to `pkgs/development/interpreters/python/cpython/default.nix`
running `lib.filterAttrs (n: v: ! lib.isDerivation v && n != "passthruFun")` on it's inputs (2 of them are darwin only)
the `throw "Unsupported sdk...` in `pkgs/top-level/darwin-packages.nix` will be triggered.
After this change `pkgsCross.armv7a-android-prebuilt.python3.pythonOnBuildForHost` won't fail with
`error: Unsupported sdk: 33`
Issue was bisected to 3cb23cec23
The old stdenv didn't work, and was also impure. The new one works, and
is pure. Presently, the bootstrap tools are cross compiled into one small
nar and one large tar, which is then unpacked, patched, and split into
smaller derivations. Efforts were made to make the boot process as short
as possible - there are only two clangs built, and as many packages are
propagated between stages as possible while leaving the bootstrap tools
out of the final stdenv's closure.
Previously we would fallback to using `kernel` as the `os` which would
result in using the wrong `os` value (`none`) when actually we want
`unknown`. This seems to be a special case for wasm32-unknown-unknown
and wasm64-unknown-unknown so I extended the if statement to support it.
`rustc.config` is called `rust.rustcTarget` now, and
`{rustc -> rust}.platform`.
This is the new way (tm), and is preferred since
https://github.com/NixOS/nixpkgs/pull/271707 -
though the documentation still is outdated, and some expressions in
nixpkgs were using the old interface.
This updates both.
* Extend libc
Include non-libc core libraries in the libc package. Many of these
mirror libraries present in glibc on linux, such as libgcc, libraries
used for iconv, and libraries used for reading kernel info (libkvm,
libprocstat, libmemstat).
Without this many packages outside the freebsd tree would need to be
modified to include standard dependencies which would already be on
the system for other packages.
* Mark FreeBSD as using LLVM
* Update default LLVM version FreeBSD
* Use patch monolith
The patchesRoot system combined with the fact that each derivation
will Request specific names of patches makes it very annoying to use
other FreeBSD source trees with nixpkgs. This new system allows
providing one Or more entire trees of patches whose contents will be
dynamically Parsed and only the relevant patches will be applied for
any one Derivation.
With this commit, the following knobs are available for specifying the
FreeBSD source:
- overriding `freebsd.versionInfo`, for picking another official
supported FreeBSD release.
- overriding `freebsd.source` for specifying a specific unpatched
FreeBSD source tree.
- overriding `freebsd.patches`, for specifying the patches to apply.
Co-Authored-by: Audrey Dutcher <audrey@rhelmot.io>
Co-Authored-by: John Ericson <John.Ericson@Obsidian.Systems>
This allows refactoring in the file without accidentally modifying the
public interface of the file.
Also, pull in symbols consistently from `lib` instead of `builtins`.
According to the WebAssembly design doc, wasm32 is an ILP32 ABI like
x32, mips64n32, and aarch64_ilp32 (Apple Watch). This commits adds
it to the predicate.
1319968ca5/CAndC%2B%2B.md (L16)
Most of the time when we do a patchelf conditional on
hostPlatform.isLinux, what we really mean is hostPlatform.isElf.
Now that we are starting to support BSDs, this is becoming more important.
An important idea around the rust stuff in lib.systems is that it's
elaborated — this means that it should idempotently add to the values
passed in, if any. But we missed that the names used for the
parameter and the elaborated value for "rustcTarget"/"config" didn't
line up. The intention was to use "rustcTarget" everywhere in the new
interface, as a more descriptive name than "config".
This fixes setting the system in NixOS configuration, which results in
an already elaborated system being elaborated again. Before, this
wouldn't produce the correct result:
% nix-instantiate --eval -A stdenv.hostPlatform.rust.rustcTarget --system armv7l-linux
"armv7-unknown-linux-gnueabihf"
% NIX_PATH= nix-instantiate --eval -E '(import nixos/lib/eval-config.nix { system = "armv7l-linux"; modules = []; }).pkgs.stdenv.hostPlatform.rust.rustcTarget'
"arm-unknown-linux-gnueabihf"
Fixes: e3e57b8f18 ("lib.systems: elaborate Rust metadata")
Fixes: https://github.com/NixOS/nixpkgs/issues/271000
Usually, attributes passed explicitly to elaborate take precedence
over the elaborated ones, but since we also elaborate the nested
"rust" attrset, we need to push that one level down, so the rest of
"rust" is still filled in if you just pass
{ rust = { config = ... } }.
I've had to drop the assertion that checked that at most one of "rust"
and "rustc" was part of the un-elaborated system, because doing this
broke passing an elaborated system in, which should be idempotent.
For the same reason, I've also had to make it possible for
rust.rustcTargetSpec to be passed in. Otherwise, on the second call,
since platform was filled in by the first, the custom target file
would be constructed. The only other way to avoid this would be to
compare the platform attrs to all built in Rust targets to check it
wasn't one of those, and that isn't feasible.
Fixes: e3e57b8f18 ("lib.systems: elaborate Rust metadata")
