- concrete types start with uppercase: Int, String, Bool, Derivation,
etc.
- type variables start with lowercase: a, b, etc.
- list:
- use `[x]` for homogeneous lists instead of `List x` or `[ x ]`
- use `List` for heterogeneous lists (not that common in `lib`)
- attr:
- use `AttrSet` for a generic attribute set type
- use `{ key1 :: Type1; key2 :: Type2; ... }` for adding signatures
for known attribute names and types
- use `{ key1 = value1; key2 = value2; ... }` for adding attributes
with known literals
- end with an ellipsis (`...`) if the set can contain unknown
attributes
- use `{ [String] :: x }` if all the attributes has the same type `x`
- prefer `Any` over `a` if the latter is not reused
Make rustcTargetSpec the primary entrypoint for setting a custom target,
and wire up all the other stuff so they are hopefully as working and as
broken as before.
In particular, to specify a custom target, the user now just specifies
rust.rustcTargetSpec. rust.platform and rust.cargoShortTarget are
populated from rust.rustcTargetSpec now. In addition, rust.rustcTarget
defaults to rust.cargoShortTarget. (rust.rustcTarget and
rust.cargoShortTarget really should always be the same, but I think we
can deal with that later).
This allows the user to more easily control the basename of
rust.rustcTargetSpec by passing e.g.
"${./rust}/mips64el_mips3-unknown-linux-gnuabi64.json", which allows
cc-rs and in turn std to work.
Rust does not know how to parse "gnuabielfv{1,2}", so simplify those down to just "gnu".
This obsoletes the manual rustcTarget fix in the ppc64-elfv1 example.
The old cygwin support used -pc-windows-cygnus as the config. This is
supported by LLVM, but not by GNU. This will change it to -pc-cygwin,
which is more generally supported.
Because the kernel is now 'cygwin' rather than 'windows', isWindows will
return false. There are lots of different reasons isWindows is used in
nixpkgs, but in my experience they often have to do with posix
compatibility and don't apply to cygwin.
Co-authored-by: Brian McKenna <brian@brianmckenna.org>
this architecture mapping is used broadly in the node ecosystem.
an assortment of tools and hooks, like buildNpmPackage or
pnpm.configHook, will benefit from reusing these values. placing them in
stdenv makes sense because (1) several of these tools don't currently
depend on nodejs, and may even be available where nodejs is not and (2)
`stdenv.{build,host,target}Platform` seems to be less error-prone than
`pkgs*.nodejs.{os,arch}` -- especially for setup hooks where the offsets
are shifted.
ELFv1 is the historically better supported one on glibc, ELFv2 seems to have some issues with our toolchain.
Restore the option to pick the ABI with pkgsCross.
