armv6l-linux was incorrectly added to the list of platforms without host
tools in #227987. arm-unknown-linux-gnueabihf is present in the list of
Tier 2 targets with host tools, and this target corresponds to our
armv6l-linux platform.
Members of the [package] table in Cargo.toml can be either subtables, or
values like strings and bools. Python is happy to check for membership
of "workspace" in a string, since Python strings are iterables, but if
the value is a bool, Python will throw an exception.
rustc supports way more platforms than Linux and Darwin. We might not
be able to build it for every platform at the moment, but that's what
meta.broken is for.
There are other platforms that rustc can produce binaries for, but
can't run on itself, so those are listed in the defaults for
buildRustPackage.
Without this PR, unlike `RUST_LIB_BACKTRACE=1 cargo run` you won't
get line numbers in backtraces from binaries built with:
```
nix build -f Cargo.nix --arg release false
```
This PR fixes that.
The build.rs script shipped with evdev-sys attempts to detect cross
compilation and uses a completely different codepath which does a
`git fetch` inside the build script. This doesn't work in nixpkgs.
This PR adds a `touch libevdev/.git` to trick the `build.rs` into
thinking that it is not necessary to do a `git fetch`.
Thanks to @figsoda for finding this more-elegant solution to the
problem (my original solution needed to patch `build.rs`):
https://github.com/NixOS/nixpkgs/pull/224893#pullrequestreview-1373809617
Tested on:
- [x] `aarch64-linux` (cross from `x86_64-linux`)
The reason is that we can not expect the extended logic run on git
dependencies starting from Cargo 1.68 to be reproducible in future
versions, and thus the output hash would not be sufficiently stable.
https://github.com/rust-lang/cargo/pull/11414
Since we grep for 'workspace', it's possible the script ends up running
on a Cargo.toml that has the word 'workspace' in a comment, but does not
actually use workspaces
Rust 1.64.0 added support for workspace inheritance, which allows
for crates to inherit values such as dependency version constraints or
package metadata information from their workspaces [0].
This works by having workspace members specify a value as a table, with
`workspace` set to true. Thus, supporting this in importCargoLock is as
simple as walking the crate's Cargo.toml, replacing inherited values
with their workspace counterpart.
This is also what a forthcoming Cargo release will do for `cargo vendor` [1],
but we can get ahead of it ;)
[0]: https://blog.rust-lang.org/2022/09/22/Rust-1.64.0.html#cargo-improvements-workspace-inheritance-and-multi-target-builds
[1]: https://github.com/rust-lang/cargo/pull/11414
