2017-07-29 00:05:35 +00:00
|
|
|
{ lib }:
|
2017-05-21 17:39:23 +00:00
|
|
|
|
2024-03-12 15:32:54 +00:00
|
|
|
let
|
|
|
|
inherit (lib)
|
|
|
|
any
|
|
|
|
filterAttrs
|
|
|
|
foldl
|
|
|
|
hasInfix
|
|
|
|
isFunction
|
|
|
|
isList
|
|
|
|
isString
|
|
|
|
mapAttrs
|
|
|
|
optional
|
|
|
|
optionalAttrs
|
|
|
|
optionalString
|
|
|
|
removeSuffix
|
|
|
|
replaceStrings
|
|
|
|
toUpper
|
|
|
|
;
|
|
|
|
|
|
|
|
inherit (lib.strings) toJSON;
|
|
|
|
|
2017-07-29 00:05:35 +00:00
|
|
|
doubles = import ./doubles.nix { inherit lib; };
|
|
|
|
parse = import ./parse.nix { inherit lib; };
|
|
|
|
inspect = import ./inspect.nix { inherit lib; };
|
|
|
|
platforms = import ./platforms.nix { inherit lib; };
|
|
|
|
examples = import ./examples.nix { inherit lib; };
|
2020-08-05 02:32:41 +00:00
|
|
|
architectures = import ./architectures.nix { inherit lib; };
|
2022-04-11 20:11:29 +00:00
|
|
|
|
2024-04-04 14:36:07 +00:00
|
|
|
/**
|
2023-05-14 20:28:31 +00:00
|
|
|
Elaborated systems contain functions, which means that they don't satisfy
|
|
|
|
`==` for a lack of reflexivity.
|
|
|
|
|
|
|
|
They might *appear* to satisfy `==` reflexivity when the same exact value is
|
|
|
|
compared to itself, because object identity is used as an "optimization";
|
|
|
|
compare the value with a reconstruction of itself, e.g. with `f == a: f a`,
|
|
|
|
or perhaps calling `elaborate` twice, and one will see reflexivity fail as described.
|
|
|
|
|
|
|
|
Hence a custom equality test.
|
|
|
|
|
|
|
|
Note that this does not canonicalize the systems, so you'll want to make sure
|
|
|
|
both arguments have been `elaborate`-d.
|
|
|
|
*/
|
|
|
|
equals =
|
2024-03-12 15:32:54 +00:00
|
|
|
let removeFunctions = a: filterAttrs (_: v: !isFunction v) a;
|
2023-06-13 08:22:06 +00:00
|
|
|
in a: b: removeFunctions a == removeFunctions b;
|
2023-05-14 20:28:31 +00:00
|
|
|
|
2024-04-04 14:36:07 +00:00
|
|
|
/**
|
|
|
|
List of all Nix system doubles the nixpkgs flake will expose the package set
|
|
|
|
for. All systems listed here must be supported by nixpkgs as `localSystem`.
|
2022-04-11 20:11:29 +00:00
|
|
|
|
2024-04-04 14:36:07 +00:00
|
|
|
:::{.warning}
|
|
|
|
This attribute is considered experimental and is subject to change.
|
|
|
|
:::
|
2022-04-11 20:11:29 +00:00
|
|
|
*/
|
|
|
|
flakeExposed = import ./flake-systems.nix { };
|
|
|
|
|
2017-03-24 00:49:28 +00:00
|
|
|
# Elaborate a `localSystem` or `crossSystem` so that it contains everything
|
|
|
|
# necessary.
|
|
|
|
#
|
|
|
|
# `parsed` is inferred from args, both because there are two options with one
|
2022-12-17 23:59:29 +00:00
|
|
|
# clearly preferred, and to prevent cycles. A simpler fixed point where the RHS
|
2017-03-24 00:49:28 +00:00
|
|
|
# always just used `final.*` would fail on both counts.
|
2019-06-04 15:10:03 +00:00
|
|
|
elaborate = args': let
|
2024-03-12 15:32:54 +00:00
|
|
|
args = if isString args' then { system = args'; }
|
2019-06-04 15:10:03 +00:00
|
|
|
else args';
|
lib.systems: elaborate Rust metadata
We need this stuff to be available in lib so make-derivation.nix can
access it to construct the Meson cross file.
This has a couple of other advantages:
- It makes Rust less special. Now figuring out what Rust calls a
platform is the same as figuring out what Linux or QEMU call it.
- We can unify the schema used to define Rust targets, and the schema
used to access those values later. Just like you can set "config"
or "system" in a platform definition, and then access those same
keys on the elaborated platform, you can now set "rustcTarget" in
your crossSystem, and then access "stdenv.hostPlatform.rustcTarget"
in your code.
"rustcTarget", "rustcTargetSpec", "cargoShortTarget", and
"cargoEnvVarTarget" have the "rustc" and "cargo" prefixes because
these are not exposed to code by the compiler, and are not
standardized. The arch/os/etc. variables are all named to match the
forms in the Rust target spec JSON.
The new rust.target-family only takes a list, since we don't need to
worry about backwards compatibility when that name is used.
The old APIs are all still functional with no warning for now, so that
it's possible for external code to use a single API on both 23.05 and
23.11. We can introduce the warnings once 23.05 is EOL, and make them
hard errors when 23.11 is EOL.
2023-05-09 13:38:32 +00:00
|
|
|
|
|
|
|
# TODO: deprecate args.rustc in favour of args.rust after 23.05 is EOL.
|
lib.systems.elaborate: fix passing `rust`
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: e3e57b8f1885 ("lib.systems: elaborate Rust metadata")
2023-11-17 19:16:22 +00:00
|
|
|
rust = args.rust or args.rustc or {};
|
lib.systems: elaborate Rust metadata
We need this stuff to be available in lib so make-derivation.nix can
access it to construct the Meson cross file.
This has a couple of other advantages:
- It makes Rust less special. Now figuring out what Rust calls a
platform is the same as figuring out what Linux or QEMU call it.
- We can unify the schema used to define Rust targets, and the schema
used to access those values later. Just like you can set "config"
or "system" in a platform definition, and then access those same
keys on the elaborated platform, you can now set "rustcTarget" in
your crossSystem, and then access "stdenv.hostPlatform.rustcTarget"
in your code.
"rustcTarget", "rustcTargetSpec", "cargoShortTarget", and
"cargoEnvVarTarget" have the "rustc" and "cargo" prefixes because
these are not exposed to code by the compiler, and are not
standardized. The arch/os/etc. variables are all named to match the
forms in the Rust target spec JSON.
The new rust.target-family only takes a list, since we don't need to
worry about backwards compatibility when that name is used.
The old APIs are all still functional with no warning for now, so that
it's possible for external code to use a single API on both 23.05 and
23.11. We can introduce the warnings once 23.05 is EOL, and make them
hard errors when 23.11 is EOL.
2023-05-09 13:38:32 +00:00
|
|
|
|
2017-03-24 00:49:28 +00:00
|
|
|
final = {
|
|
|
|
# Prefer to parse `config` as it is strictly more informative.
|
|
|
|
parsed = parse.mkSystemFromString (if args ? config then args.config else args.system);
|
|
|
|
# Either of these can be losslessly-extracted from `parsed` iff parsing succeeds.
|
|
|
|
system = parse.doubleFromSystem final.parsed;
|
|
|
|
config = parse.tripleFromSystem final.parsed;
|
2022-04-26 20:17:48 +00:00
|
|
|
# Determine whether we can execute binaries built for the provided platform.
|
|
|
|
canExecute = platform:
|
2022-06-25 22:05:23 +00:00
|
|
|
final.isAndroid == platform.isAndroid &&
|
2022-04-26 20:17:48 +00:00
|
|
|
parse.isCompatible final.parsed.cpu platform.parsed.cpu
|
|
|
|
&& final.parsed.kernel == platform.parsed.kernel;
|
2022-05-23 19:23:17 +00:00
|
|
|
isCompatible = _: throw "2022-05-23: isCompatible has been removed in favor of canExecute, refer to the 22.11 changelog for details";
|
2017-02-17 05:36:10 +00:00
|
|
|
# Derived meta-data
|
2017-05-21 18:02:19 +00:00
|
|
|
libc =
|
2017-02-17 05:36:10 +00:00
|
|
|
/**/ if final.isDarwin then "libSystem"
|
|
|
|
else if final.isMinGW then "msvcrt"
|
2019-01-30 02:01:24 +00:00
|
|
|
else if final.isWasi then "wasilibc"
|
2020-07-21 20:11:36 +00:00
|
|
|
else if final.isRedox then "relibc"
|
2017-02-17 05:36:10 +00:00
|
|
|
else if final.isMusl then "musl"
|
2018-05-10 03:33:31 +00:00
|
|
|
else if final.isUClibc then "uclibc"
|
2017-02-17 05:36:10 +00:00
|
|
|
else if final.isAndroid then "bionic"
|
|
|
|
else if final.isLinux /* default */ then "glibc"
|
2022-10-31 12:35:51 +00:00
|
|
|
else if final.isFreeBSD then "fblibc"
|
|
|
|
else if final.isNetBSD then "nblibc"
|
2018-10-15 01:41:33 +00:00
|
|
|
else if final.isAvr then "avrlibc"
|
2023-04-26 13:07:19 +00:00
|
|
|
else if final.isGhcjs then null
|
2020-02-22 17:37:46 +00:00
|
|
|
else if final.isNone then "newlib"
|
2017-05-21 18:02:19 +00:00
|
|
|
# TODO(@Ericson2314) think more about other operating systems
|
2017-02-17 05:36:10 +00:00
|
|
|
else "native/impure";
|
2021-05-01 03:03:19 +00:00
|
|
|
# Choose what linker we wish to use by default. Someday we might also
|
|
|
|
# choose the C compiler, runtime library, C++ standard library, etc. in
|
|
|
|
# this way, nice and orthogonally, and deprecate `useLLVM`. But due to
|
|
|
|
# the monolithic GCC build we cannot actually make those choices
|
|
|
|
# independently, so we are just doing `linker` and keeping `useLLVM` for
|
|
|
|
# now.
|
|
|
|
linker =
|
|
|
|
/**/ if final.useLLVM or false then "lld"
|
|
|
|
else if final.isDarwin then "cctools"
|
2022-12-17 23:59:29 +00:00
|
|
|
# "bfd" and "gold" both come from GNU binutils. The existence of Gold
|
2021-05-01 03:03:19 +00:00
|
|
|
# is why we use the more obscure "bfd" and not "binutils" for this
|
|
|
|
# choice.
|
|
|
|
else "bfd";
|
2023-11-25 03:51:50 +00:00
|
|
|
# The standard lib directory name that non-nixpkgs binaries distributed
|
|
|
|
# for this platform normally assume.
|
|
|
|
libDir = if final.isLinux then
|
|
|
|
if final.isx86_64 || final.isMips64 || final.isPower64
|
|
|
|
then "lib64"
|
|
|
|
else "lib"
|
|
|
|
else null;
|
2024-03-12 15:32:54 +00:00
|
|
|
extensions = optionalAttrs final.hasSharedLibraries {
|
2023-07-04 20:09:27 +00:00
|
|
|
sharedLibrary =
|
|
|
|
if final.isDarwin then ".dylib"
|
2017-09-12 19:24:03 +00:00
|
|
|
else if final.isWindows then ".dll"
|
|
|
|
else ".so";
|
2023-07-04 20:09:27 +00:00
|
|
|
} // {
|
2022-08-15 00:10:01 +00:00
|
|
|
staticLibrary =
|
|
|
|
/**/ if final.isWindows then ".lib"
|
|
|
|
else ".a";
|
|
|
|
library =
|
2023-07-04 20:09:27 +00:00
|
|
|
/**/ if final.isStatic then final.extensions.staticLibrary
|
|
|
|
else final.extensions.sharedLibrary;
|
2017-09-12 19:24:03 +00:00
|
|
|
executable =
|
|
|
|
/**/ if final.isWindows then ".exe"
|
|
|
|
else "";
|
|
|
|
};
|
2017-02-17 05:36:10 +00:00
|
|
|
# Misc boolean options
|
|
|
|
useAndroidPrebuilt = false;
|
2018-04-15 23:21:45 +00:00
|
|
|
useiOSPrebuilt = false;
|
2018-10-17 02:48:43 +00:00
|
|
|
|
|
|
|
# Output from uname
|
|
|
|
uname = {
|
|
|
|
# uname -s
|
2018-10-17 19:43:49 +00:00
|
|
|
system = {
|
2019-08-13 21:52:01 +00:00
|
|
|
linux = "Linux";
|
|
|
|
windows = "Windows";
|
|
|
|
darwin = "Darwin";
|
|
|
|
netbsd = "NetBSD";
|
|
|
|
freebsd = "FreeBSD";
|
|
|
|
openbsd = "OpenBSD";
|
|
|
|
wasi = "Wasi";
|
2020-07-21 20:11:36 +00:00
|
|
|
redox = "Redox";
|
2020-03-24 08:02:18 +00:00
|
|
|
genode = "Genode";
|
2018-10-17 19:43:49 +00:00
|
|
|
}.${final.parsed.kernel.name} or null;
|
2018-10-17 02:48:43 +00:00
|
|
|
|
2022-09-06 15:17:09 +00:00
|
|
|
# uname -m
|
2022-09-06 05:02:30 +00:00
|
|
|
processor =
|
|
|
|
if final.isPower64
|
2024-03-12 15:32:54 +00:00
|
|
|
then "ppc64${optionalString final.isLittleEndian "le"}"
|
2022-09-06 05:02:30 +00:00
|
|
|
else if final.isPower
|
2024-03-12 15:32:54 +00:00
|
|
|
then "ppc${optionalString final.isLittleEndian "le"}"
|
2022-09-06 05:02:30 +00:00
|
|
|
else if final.isMips64
|
|
|
|
then "mips64" # endianness is *not* included on mips64
|
|
|
|
else final.parsed.cpu.name;
|
2018-10-17 02:48:43 +00:00
|
|
|
|
|
|
|
# uname -r
|
|
|
|
release = null;
|
|
|
|
};
|
2023-06-29 06:49:38 +00:00
|
|
|
|
|
|
|
# It is important that hasSharedLibraries==false when the platform has no
|
|
|
|
# dynamic library loader. Various tools (including the gcc build system)
|
|
|
|
# have knowledge of which platforms are incapable of dynamic linking, and
|
|
|
|
# will still build on/for those platforms with --enable-shared, but simply
|
|
|
|
# omit any `.so` build products such as libgcc_s.so. When that happens,
|
|
|
|
# it causes hard-to-troubleshoot build failures.
|
|
|
|
hasSharedLibraries = with final;
|
|
|
|
(isAndroid || isGnu || isMusl # Linux (allows multiple libcs)
|
|
|
|
|| isDarwin || isSunOS || isOpenBSD || isFreeBSD || isNetBSD # BSDs
|
|
|
|
|| isCygwin || isMinGW # Windows
|
|
|
|
) && !isStatic;
|
|
|
|
|
|
|
|
# The difference between `isStatic` and `hasSharedLibraries` is mainly the
|
|
|
|
# addition of the `staticMarker` (see make-derivation.nix). Some
|
|
|
|
# platforms, like embedded machines without a libc (e.g. arm-none-eabi)
|
|
|
|
# don't support dynamic linking, but don't get the `staticMarker`.
|
|
|
|
# `pkgsStatic` sets `isStatic=true`, so `pkgsStatic.hostPlatform` always
|
|
|
|
# has the `staticMarker`.
|
2020-08-25 01:46:48 +00:00
|
|
|
isStatic = final.isWasm || final.isRedox;
|
2018-11-13 22:54:08 +00:00
|
|
|
|
2021-01-23 01:33:55 +00:00
|
|
|
# Just a guess, based on `system`
|
|
|
|
inherit
|
|
|
|
({
|
|
|
|
linux-kernel = args.linux-kernel or {};
|
|
|
|
gcc = args.gcc or {};
|
|
|
|
} // platforms.select final)
|
lib.systems: elaborate Rust metadata
We need this stuff to be available in lib so make-derivation.nix can
access it to construct the Meson cross file.
This has a couple of other advantages:
- It makes Rust less special. Now figuring out what Rust calls a
platform is the same as figuring out what Linux or QEMU call it.
- We can unify the schema used to define Rust targets, and the schema
used to access those values later. Just like you can set "config"
or "system" in a platform definition, and then access those same
keys on the elaborated platform, you can now set "rustcTarget" in
your crossSystem, and then access "stdenv.hostPlatform.rustcTarget"
in your code.
"rustcTarget", "rustcTargetSpec", "cargoShortTarget", and
"cargoEnvVarTarget" have the "rustc" and "cargo" prefixes because
these are not exposed to code by the compiler, and are not
standardized. The arch/os/etc. variables are all named to match the
forms in the Rust target spec JSON.
The new rust.target-family only takes a list, since we don't need to
worry about backwards compatibility when that name is used.
The old APIs are all still functional with no warning for now, so that
it's possible for external code to use a single API on both 23.05 and
23.11. We can introduce the warnings once 23.05 is EOL, and make them
hard errors when 23.11 is EOL.
2023-05-09 13:38:32 +00:00
|
|
|
linux-kernel gcc;
|
|
|
|
|
|
|
|
# TODO: remove after 23.05 is EOL, with an error pointing to the rust.* attrs.
|
|
|
|
rustc = args.rustc or {};
|
|
|
|
|
2021-01-23 01:33:55 +00:00
|
|
|
linuxArch =
|
2019-04-19 18:51:25 +00:00
|
|
|
if final.isAarch32 then "arm"
|
|
|
|
else if final.isAarch64 then "arm64"
|
2021-01-23 01:33:55 +00:00
|
|
|
else if final.isx86_32 then "i386"
|
|
|
|
else if final.isx86_64 then "x86_64"
|
2022-06-20 07:56:34 +00:00
|
|
|
# linux kernel does not distinguish microblaze/microblazeel
|
|
|
|
else if final.isMicroBlaze then "microblaze"
|
lib/systems: add mips64el definitions
MIPS has a large space of {architecture,abi,endianness}; this commit
adds all of them to lib/systems/platforms.nix so we can be done with
it.
Currently lib/systems/inspect.nix has a single "isMips" predicate,
which is a bit ambiguous now that we will have both mips32 and mips64
support, with the latter having two ABIs. Let's add four new
predicates (isMips32, isMips64, isMips64n32, and isMips64n64) and
treat the now-ambiguous isMips as deprecated in favor of the
more-specific predicates. These predicates are used mainly for
enabling/disabling target-specific workarounds, and it is extremely
rare that a platform-specific workaround is needed, and both mips32
and mips64 need exactly the same workaround.
The separate predicates (isMips64n32 and isMips64n64) for ABI
distinctions are, unfortunately, useful. Boost's user-scheduled
threading (used by nix) does does not currently supports mips64n32,
which is a very desirable ABI on routers since they rarely have
more than 2**32 bytes of DRAM.
2022-02-21 04:32:52 +00:00
|
|
|
else if final.isMips32 then "mips"
|
|
|
|
else if final.isMips64 then "mips" # linux kernel does not distinguish mips32/mips64
|
2021-01-26 01:55:04 +00:00
|
|
|
else if final.isPower then "powerpc"
|
|
|
|
else if final.isRiscV then "riscv"
|
2021-09-07 09:10:38 +00:00
|
|
|
else if final.isS390 then "s390"
|
2023-04-27 17:04:17 +00:00
|
|
|
else if final.isLoongArch64 then "loongarch"
|
2019-04-19 18:51:25 +00:00
|
|
|
else final.parsed.cpu.name;
|
|
|
|
|
2023-08-14 08:32:29 +00:00
|
|
|
# https://source.denx.de/u-boot/u-boot/-/blob/9bfb567e5f1bfe7de8eb41f8c6d00f49d2b9a426/common/image.c#L81-106
|
|
|
|
ubootArch =
|
|
|
|
if final.isx86_32 then "x86" # not i386
|
|
|
|
else if final.isMips64 then "mips64" # uboot *does* distinguish between mips32/mips64
|
|
|
|
else final.linuxArch; # other cases appear to agree with linuxArch
|
|
|
|
|
2018-11-13 22:54:08 +00:00
|
|
|
qemuArch =
|
2020-02-05 18:54:54 +00:00
|
|
|
if final.isAarch32 then "arm"
|
2023-03-01 14:38:34 +00:00
|
|
|
else if final.isS390 && !final.isS390x then null
|
2018-11-13 22:54:08 +00:00
|
|
|
else if final.isx86_64 then "x86_64"
|
|
|
|
else if final.isx86 then "i386"
|
2024-03-12 15:32:54 +00:00
|
|
|
else if final.isMips64n32 then "mipsn32${optionalString final.isLittleEndian "el"}"
|
|
|
|
else if final.isMips64 then "mips64${optionalString final.isLittleEndian "el"}"
|
2022-09-06 05:02:30 +00:00
|
|
|
else final.uname.processor;
|
2018-11-13 22:54:08 +00:00
|
|
|
|
2022-09-27 12:10:45 +00:00
|
|
|
# Name used by UEFI for architectures.
|
|
|
|
efiArch =
|
|
|
|
if final.isx86_32 then "ia32"
|
|
|
|
else if final.isx86_64 then "x64"
|
|
|
|
else if final.isAarch32 then "arm"
|
|
|
|
else if final.isAarch64 then "aa64"
|
|
|
|
else final.parsed.cpu.name;
|
|
|
|
|
2020-12-11 11:15:34 +00:00
|
|
|
darwinArch = {
|
|
|
|
armv7a = "armv7";
|
|
|
|
aarch64 = "arm64";
|
|
|
|
}.${final.parsed.cpu.name} or final.parsed.cpu.name;
|
|
|
|
|
2021-02-05 07:24:43 +00:00
|
|
|
darwinPlatform =
|
|
|
|
if final.isMacOS then "macos"
|
|
|
|
else if final.isiOS then "ios"
|
|
|
|
else null;
|
|
|
|
# The canonical name for this attribute is darwinSdkVersion, but some
|
|
|
|
# platforms define the old name "sdkVer".
|
2021-02-15 06:45:37 +00:00
|
|
|
darwinSdkVersion = final.sdkVer or (if final.isAarch64 then "11.0" else "10.12");
|
2021-02-05 07:24:43 +00:00
|
|
|
darwinMinVersion = final.darwinSdkVersion;
|
2021-04-10 09:06:25 +00:00
|
|
|
darwinMinVersionVariable =
|
|
|
|
if final.isMacOS then "MACOSX_DEPLOYMENT_TARGET"
|
|
|
|
else if final.isiOS then "IPHONEOS_DEPLOYMENT_TARGET"
|
|
|
|
else null;
|
2022-09-06 18:43:33 +00:00
|
|
|
} // (
|
|
|
|
let
|
|
|
|
selectEmulator = pkgs:
|
|
|
|
let
|
|
|
|
qemu-user = pkgs.qemu.override {
|
|
|
|
smartcardSupport = false;
|
|
|
|
spiceSupport = false;
|
|
|
|
openGLSupport = false;
|
|
|
|
virglSupport = false;
|
|
|
|
vncSupport = false;
|
|
|
|
gtkSupport = false;
|
|
|
|
sdlSupport = false;
|
2024-03-12 01:16:01 +00:00
|
|
|
alsaSupport = false;
|
2022-09-06 18:43:33 +00:00
|
|
|
pulseSupport = false;
|
2023-09-07 21:23:19 +00:00
|
|
|
pipewireSupport = false;
|
2024-03-12 01:16:01 +00:00
|
|
|
jackSupport = false;
|
2022-09-06 18:43:33 +00:00
|
|
|
smbdSupport = false;
|
|
|
|
seccompSupport = false;
|
2024-03-12 01:16:01 +00:00
|
|
|
tpmSupport = false;
|
|
|
|
capstoneSupport = false;
|
2023-04-21 21:38:56 +00:00
|
|
|
enableDocs = false;
|
2022-09-06 18:43:33 +00:00
|
|
|
hostCpuTargets = [ "${final.qemuArch}-linux-user" ];
|
|
|
|
};
|
2022-11-06 19:10:25 +00:00
|
|
|
wine = (pkgs.winePackagesFor "wine${toString final.parsed.cpu.bits}").minimal;
|
2022-09-06 18:43:33 +00:00
|
|
|
in
|
2023-06-18 21:39:09 +00:00
|
|
|
if pkgs.stdenv.hostPlatform.canExecute final
|
2022-09-06 18:43:33 +00:00
|
|
|
then "${pkgs.runtimeShell} -c '\"$@\"' --"
|
|
|
|
else if final.isWindows
|
2024-03-12 15:32:54 +00:00
|
|
|
then "${wine}/bin/wine${optionalString (final.parsed.cpu.bits == 64) "64"}"
|
2023-03-01 14:38:34 +00:00
|
|
|
else if final.isLinux && pkgs.stdenv.hostPlatform.isLinux && final.qemuArch != null
|
2022-09-06 18:43:33 +00:00
|
|
|
then "${qemu-user}/bin/qemu-${final.qemuArch}"
|
|
|
|
else if final.isWasi
|
|
|
|
then "${pkgs.wasmtime}/bin/wasmtime"
|
|
|
|
else if final.isMmix
|
|
|
|
then "${pkgs.mmixware}/bin/mmix"
|
|
|
|
else null;
|
|
|
|
in {
|
|
|
|
emulatorAvailable = pkgs: (selectEmulator pkgs) != null;
|
2021-02-05 07:24:43 +00:00
|
|
|
|
2022-09-06 18:43:33 +00:00
|
|
|
emulator = pkgs:
|
|
|
|
if (final.emulatorAvailable pkgs)
|
|
|
|
then selectEmulator pkgs
|
|
|
|
else throw "Don't know how to run ${final.config} executables.";
|
2018-11-13 22:54:08 +00:00
|
|
|
|
2022-09-06 18:43:33 +00:00
|
|
|
}) // mapAttrs (n: v: v final.parsed) inspect.predicates
|
2021-01-23 01:33:55 +00:00
|
|
|
// mapAttrs (n: v: v final.gcc.arch or "default") architectures.predicates
|
lib.systems.elaborate: fix passing `rust`
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: e3e57b8f1885 ("lib.systems: elaborate Rust metadata")
2023-11-17 19:16:22 +00:00
|
|
|
// args // {
|
|
|
|
rust = rust // {
|
|
|
|
# Once args.rustc.platform.target-family is deprecated and
|
|
|
|
# removed, there will no longer be any need to modify any
|
|
|
|
# values from args.rust.platform, so we can drop all the
|
|
|
|
# "args ? rust" etc. checks, and merge args.rust.platform in
|
|
|
|
# /after/.
|
|
|
|
platform = rust.platform or {} // {
|
|
|
|
# https://doc.rust-lang.org/reference/conditional-compilation.html#target_arch
|
|
|
|
arch =
|
|
|
|
/**/ if rust ? platform then rust.platform.arch
|
|
|
|
else if final.isAarch32 then "arm"
|
|
|
|
else if final.isMips64 then "mips64" # never add "el" suffix
|
|
|
|
else if final.isPower64 then "powerpc64" # never add "le" suffix
|
|
|
|
else final.parsed.cpu.name;
|
|
|
|
|
|
|
|
# https://doc.rust-lang.org/reference/conditional-compilation.html#target_os
|
|
|
|
os =
|
|
|
|
/**/ if rust ? platform then rust.platform.os or "none"
|
|
|
|
else if final.isDarwin then "macos"
|
|
|
|
else final.parsed.kernel.name;
|
|
|
|
|
|
|
|
# https://doc.rust-lang.org/reference/conditional-compilation.html#target_family
|
|
|
|
target-family =
|
|
|
|
/**/ if args ? rust.platform.target-family then args.rust.platform.target-family
|
|
|
|
else if args ? rustc.platform.target-family
|
|
|
|
then
|
|
|
|
(
|
|
|
|
# Since https://github.com/rust-lang/rust/pull/84072
|
|
|
|
# `target-family` is a list instead of single value.
|
|
|
|
let
|
|
|
|
f = args.rustc.platform.target-family;
|
|
|
|
in
|
2024-03-12 15:32:54 +00:00
|
|
|
if isList f then f else [ f ]
|
lib.systems.elaborate: fix passing `rust`
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: e3e57b8f1885 ("lib.systems: elaborate Rust metadata")
2023-11-17 19:16:22 +00:00
|
|
|
)
|
2024-03-12 15:32:54 +00:00
|
|
|
else optional final.isUnix "unix"
|
|
|
|
++ optional final.isWindows "windows";
|
lib.systems.elaborate: fix passing `rust`
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: e3e57b8f1885 ("lib.systems: elaborate Rust metadata")
2023-11-17 19:16:22 +00:00
|
|
|
|
|
|
|
# https://doc.rust-lang.org/reference/conditional-compilation.html#target_vendor
|
|
|
|
vendor = let
|
|
|
|
inherit (final.parsed) vendor;
|
|
|
|
in rust.platform.vendor or {
|
|
|
|
"w64" = "pc";
|
|
|
|
}.${vendor.name} or vendor.name;
|
|
|
|
};
|
|
|
|
|
|
|
|
# The name of the rust target, even if it is custom. Adjustments are
|
|
|
|
# because rust has slightly different naming conventions than we do.
|
|
|
|
rustcTarget = let
|
|
|
|
inherit (final.parsed) cpu kernel abi;
|
|
|
|
cpu_ = rust.platform.arch or {
|
|
|
|
"armv7a" = "armv7";
|
|
|
|
"armv7l" = "armv7";
|
|
|
|
"armv6l" = "arm";
|
|
|
|
"armv5tel" = "armv5te";
|
|
|
|
"riscv64" = "riscv64gc";
|
|
|
|
}.${cpu.name} or cpu.name;
|
|
|
|
vendor_ = final.rust.platform.vendor;
|
2023-12-03 00:32:01 +00:00
|
|
|
# TODO: deprecate args.rustc in favour of args.rust after 23.05 is EOL.
|
|
|
|
in args.rust.rustcTarget or args.rustc.config
|
2024-03-12 15:32:54 +00:00
|
|
|
or "${cpu_}-${vendor_}-${kernel.name}${optionalString (abi.name != "unknown") "-${abi.name}"}";
|
lib.systems.elaborate: fix passing `rust`
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: e3e57b8f1885 ("lib.systems: elaborate Rust metadata")
2023-11-17 19:16:22 +00:00
|
|
|
|
|
|
|
# The name of the rust target if it is standard, or the json file
|
|
|
|
# containing the custom target spec.
|
|
|
|
rustcTargetSpec = rust.rustcTargetSpec or (
|
|
|
|
/**/ if rust ? platform
|
2024-03-12 15:32:54 +00:00
|
|
|
then builtins.toFile (final.rust.rustcTarget + ".json") (toJSON rust.platform)
|
lib.systems.elaborate: fix passing `rust`
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: e3e57b8f1885 ("lib.systems: elaborate Rust metadata")
2023-11-17 19:16:22 +00:00
|
|
|
else final.rust.rustcTarget);
|
|
|
|
|
|
|
|
# The name of the rust target if it is standard, or the
|
|
|
|
# basename of the file containing the custom target spec,
|
|
|
|
# without the .json extension.
|
|
|
|
#
|
|
|
|
# This is the name used by Cargo for target subdirectories.
|
|
|
|
cargoShortTarget =
|
2024-03-12 15:32:54 +00:00
|
|
|
removeSuffix ".json" (baseNameOf "${final.rust.rustcTargetSpec}");
|
lib.systems.elaborate: fix passing `rust`
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: e3e57b8f1885 ("lib.systems: elaborate Rust metadata")
2023-11-17 19:16:22 +00:00
|
|
|
|
|
|
|
# When used as part of an environment variable name, triples are
|
|
|
|
# uppercased and have all hyphens replaced by underscores:
|
|
|
|
#
|
|
|
|
# https://github.com/rust-lang/cargo/pull/9169
|
|
|
|
# https://github.com/rust-lang/cargo/issues/8285#issuecomment-634202431
|
|
|
|
cargoEnvVarTarget =
|
2024-03-12 15:32:54 +00:00
|
|
|
replaceStrings ["-"] ["_"]
|
|
|
|
(toUpper final.rust.cargoShortTarget);
|
lib.systems.elaborate: fix passing `rust`
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: e3e57b8f1885 ("lib.systems: elaborate Rust metadata")
2023-11-17 19:16:22 +00:00
|
|
|
|
|
|
|
# True if the target is no_std
|
|
|
|
# https://github.com/rust-lang/rust/blob/2e44c17c12cec45b6a682b1e53a04ac5b5fcc9d2/src/bootstrap/config.rs#L415-L421
|
|
|
|
isNoStdTarget =
|
2024-03-12 15:32:54 +00:00
|
|
|
any (t: hasInfix t final.rust.rustcTarget) ["-none" "nvptx" "switch" "-uefi"];
|
lib.systems.elaborate: fix passing `rust`
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: e3e57b8f1885 ("lib.systems: elaborate Rust metadata")
2023-11-17 19:16:22 +00:00
|
|
|
};
|
|
|
|
};
|
2017-02-17 05:36:10 +00:00
|
|
|
in assert final.useAndroidPrebuilt -> final.isAndroid;
|
2024-03-12 15:32:54 +00:00
|
|
|
assert foldl
|
2018-05-09 22:50:51 +00:00
|
|
|
(pass: { assertion, message }:
|
|
|
|
if assertion final
|
|
|
|
then pass
|
|
|
|
else throw message)
|
|
|
|
true
|
|
|
|
(final.parsed.abi.assertions or []);
|
2017-02-17 05:36:10 +00:00
|
|
|
final;
|
2024-03-12 15:32:54 +00:00
|
|
|
|
|
|
|
in
|
|
|
|
|
|
|
|
# Everything in this attrset is the public interface of the file.
|
|
|
|
{
|
|
|
|
inherit
|
|
|
|
architectures
|
|
|
|
doubles
|
|
|
|
elaborate
|
|
|
|
equals
|
|
|
|
examples
|
|
|
|
flakeExposed
|
|
|
|
inspect
|
|
|
|
parse
|
|
|
|
platforms
|
|
|
|
;
|
2017-02-09 02:27:22 +00:00
|
|
|
}
|