Also begin to start work on cross compilation, though that will have to
be finished later.
The patches are based on the first version of
https://reviews.llvm.org/D99484. It's very annoying to do the
back-porting but the review has uncovered nothing super major so I'm
fine sticking with what I've got.
Beyond making the outputs work, I also strove to re-sync the packages,
as they have been drifting pointlessly apart for some time.
----
Other misc notes, highly incomplete
- lvm-config-native and llvm-config are put in `dev` because they are
tools just for build time.
- Clang no longer has an lld dep. That was introduced in
db29857eb3, but if clang needs help
finding lld when it is used we should just pass it flags / put in the
resource dir. Providing it at build time increases critical path
length for no good reason.
----
A note on `nativeCC`:
`stdenv` takes tools from the previous stage, so:
1. `pkgsBuildBuild`: `(?1, x, x)`
2. `pkgsBuildBuild.stdenv.cc`: `(?0, ?1, x)`
while:
1. `pkgsBuildBuild`: `(?1, x, x)`
2. `pkgsBuildBuild.targetPackages`: `(x, x, ?2)`
3. `pkgsBuildBuild.targetPackages.stdenv.cc`: `(?1, x, x)`
Changes the default fetcher in the Rust Platform to be the newer
`fetchCargoTarball`, and changes every application using the current default to
instead opt out.
This commit does not change any hashes or cause any rebuilds. Once integrated,
we will start deleting the opt-outs and recomputing hashes.
See #79975 for details.
Whenever we create scripts that are installed to $out, we must use runtimeShell
in order to get the shell that can be executed on the machine we create the
package for. This is relevant for cross-compiling. The only use case for
stdenv.shell are scripts that are executed as part of the build system.
Usages in checkPhase are borderline however to decrease the likelyhood
of people copying the wrong examples, I decided to use runtimeShell as well.
The easy part is to add NIX_CFLAGS_COMPILE for "regular" libraries.
A bit more tricky is to add the required flags for libclang to find
libstdcxx. For this we parse arguments to bindgen to look for
-x c++ or -xc++ and if found add NIX_CXXSTDLIB_COMPILE to the arguments.
This variable is populated by a complex dance of setupHooks. We trigger
this by adding clang to propagatedBuildInputs. A more subtle way may
exist.
Semi-automatic update generated by https://github.com/ryantm/nixpkgs-update tools.
This update was made based on information from https://repology.org/metapackage/rust-bindgen/versions.
These checks were done:
- built on NixOS
- /nix/store/y7lbrcpy05c1br43257fj056p6vf269l-rust-bindgen-0.37.0/bin/bindgen passed the binary check.
- Warning: no invocation of /nix/store/y7lbrcpy05c1br43257fj056p6vf269l-rust-bindgen-0.37.0/bin/.bindgen-wrapped had a zero exit code or showed the expected version
- 1 of 2 passed binary check by having a zero exit code.
- 1 of 2 passed binary check by having the new version present in output.
- found 0.37.0 with grep in /nix/store/y7lbrcpy05c1br43257fj056p6vf269l-rust-bindgen-0.37.0
- directory tree listing: https://gist.github.com/dab90e1565932370211bc1cb47b526d9
- du listing: https://gist.github.com/1ea884a58cb25990e712703124f8a6da
Semi-automatic update generated by https://github.com/ryantm/nixpkgs-update tools.
This update was made based on information from https://repology.org/metapackage/rust-bindgen/versions.
These checks were done:
- built on NixOS
- ran ‘/nix/store/vpn165c8nv09k30dsl7gx0crzbdzw4im-rust-bindgen-0.36.1/bin/bindgen -h’ got 0 exit code
- ran ‘/nix/store/vpn165c8nv09k30dsl7gx0crzbdzw4im-rust-bindgen-0.36.1/bin/bindgen --help’ got 0 exit code
- ran ‘/nix/store/vpn165c8nv09k30dsl7gx0crzbdzw4im-rust-bindgen-0.36.1/bin/bindgen -V’ and found version 0.36.1
- ran ‘/nix/store/vpn165c8nv09k30dsl7gx0crzbdzw4im-rust-bindgen-0.36.1/bin/bindgen --version’ and found version 0.36.1
- found 0.36.1 with grep in /nix/store/vpn165c8nv09k30dsl7gx0crzbdzw4im-rust-bindgen-0.36.1
- directory tree listing: https://gist.github.com/6731d17415819fe988768028fda0e150
The biggest benefit is that we no longer have to update the registry
package. This means that just about any cargo package can be built by
nix. No longer does `cargo update` need to be feared because it will
update to packages newer then what is available in nixpkgs.
Instead of fetching the cargo registry this bundles all the source code
into a "vendor/" folder.
This also uses the new --frozen and --locked flags which is nice.
Currently cargo-vendor only provides binaries for Linux and
macOS 64-bit. This can be solved by building it for the other
architectures and uploading it somewhere (like the NixOS cache).
This also has the downside that it requires a change to everyone's deps
hash. And if the old one is used because it was cached it will fail to
build as it will attempt to use the old version. For this reason the
attribute has been renamed to `cargoSha256`.
Authors:
* Kevin Cox <kevincox@kevincox.ca>
* Jörg Thalheim <Mic92@users.noreply.github.com>
* zimbatm <zimbatm@zimbatm.com>
