Added a cross compilation test for wasm32-unknown-unknown. This also
required using crate.metadata instead of using the regex to get rid of
the hash in the library filename. It also required adding a mkCrate
argument to assertOutputs so we can override the buildRustCrate used.
With this change you will finally be able to use
buildRustCrate/crate2nix to build your wasm32-unknown-unknown
rust projects.
Simply import nixpkgs like so:
```
lib = <nixpkgs/lib>;
pkgsForWasm32 = import <nixpkgs> {
crossSystem = lib.examples.wasm32-unknown-none;
}
```
or use pkgsCross directly with
```
pkgsCross.wasm32-unknown-none.callPackage ./. { };
```
* ocamlPackages.wtf8: use minimalOCamlVersion
* ocamlPackages.ppx_yojson_conv: minimalOCamlVersion
* ocamlPackages.postgresql: use minimalOCamlVersion
* ocamlPackages.opti: use minimalOCamlVersion
* ocamlPackages.opam-repository: use minimalOCamlVersion
* ocamlPackages.opam-format: use minimalOCamlVersion
* ocamlPackages.lwt-dllist: use minimalOCamlVersion
* ocamlPackages.lacaml: use minimalOCamlVersion
* ocamlPackages.gnuplot: use minimalOCamlVersion
* ocamlPackages.fix: use minimalOCamlVersion
* ocamlPackages.eigen: use minimalOCamlVersion
* ocamlPackages.earley: use minimalOCamlVersion
* ocamlPackages.directories: use minimalOCamlVersion
* ocamlPackages.cpuid: use minimalOCamlVersion
* build-support/ocaml: deprecate minimumOCamlVersion
* build-support/ocaml: deprecate minimumOCamlVersion
---------
Co-authored-by: Vincent Laporte <Vincent.Laporte@gmail.com>
In order to allow for the new `cargo::` prefix for build script outputs
we have to adjust the configure-crate bash scripts in buildRustCrate to
properly parse the new additional syntax.
These changes don't affect existing build scripts configured with the
old `cargo:` prefix.
For more information, see https://doc.rust-lang.org/cargo/reference/build-scripts.html#outputs-of-the-build-script
GStreamer searches for plugins relative to its binary's location.
However, since bd97973ce0, it uses its *real* binary location, breaking the FHS.
Fixes#311004 (tested on Heroic and Lutris too).
When cross compiling proc macros, the proc macro needs to be built for the
build platform's architecture.
Without this change cross compiling from Darwin to Linux would simply
fail because it tries to link to a library with a file extension that
doesn't exist on the builder's platform.
For a long time, we've had `crossLibcStdenv`, `*Cross` libc attributes,
and `*bsdCross` pre-libc package sets. This was always bad because
having "cross" things is "not declarative": the naming doesn't reflect
what packages *need* but rather how we *provide* something. This is
ugly, and creates needless friction between cross and native building.
Now, almost all of these `*Cross` attributes are gone: just these are
kept:
- Glibc's and Musl's are kept, because those packages are widely used
and I didn't want to risk changing the native builds of those at this
time.
- generic `libcCross`, `theadsCross`, and friends, because these relate
to the convolulted GCC bootstrap which still needs to be redone.
The BSD and obscure Linux or freestnanding libcs have conversely all
been made to use a new `stdenvNoLibc`, which is like the old
`crossLibcStdenv` except:
1. It usable for native and cross alike
2. It named according to what it *is* ("a standard environment without
libc but with a C compiler"), rather than some non-compositional
jargon ("the stdenv used for building libc when cross compiling",
yuck).
I should have done this change long ago, but I was stymied because of
"infinite recursions". The problem was that in too many cases we are
overriding `stdenv` to *remove* things we don't need, and this risks
cyles since those more minimal stdenvs are used to build things in the
more maximal stdenvs.
The solution is to pass `stage.nix` `stdenvNoCC`, so we can override to
*build up* rather than *tear down*. For now, the full `stdenv` is also
passed, so I don't need to change the native bootstraps, but I can see
this changing as we make things more uniform and clean those up.
Finally, the BSDs also had to be cleaned up, since they have a few
pre-libc dependencies, demanding a systematic approach. I realized what
rhelmot did in 61202561d9 (specify what
packages just need `stdenvNoLibc`) is definitely the right approach for
this, and adjusted NetBSD and OpenBSD to likewise use it.
This would cause any drv to be rebuilt when any part of the default.nix changes.
What we actually care about is the two JS files though, so simply reference them
directly.
Co-authored-by: Infinidoge <infinidoge@inx.moe>
