Cargo will never need to link for the target platform — that'd be for
the package being built to do at runtime. Cargo should know about the
build and host linkers.
This fixes e.g. pkgsCross.musl64.fd from x86_64-linux.
Fixes: 67a4f828b4 ("rust: hooks: fix cross compilation")
So in php we have a bootstrapping composer (that lives in
composer-phar.nix) that downloads the binary distribution of composer
to be able to bootstrap and build a composer built from source.
However, it's desirable to keep composer updated at all time, and this
includes the phar one that isn't used by users directly. So this makes
sure we don't "forget" about the phar one since it now borrows the
version from the source version. However, then it also made sense to
move the hash for the phar to the same file as the source
composer. Then we can control the full upgrade life cycle of both the
phar and source versions of composer from the same file.
It's useful to have access to these attributes from packages built with
buildFHSEnvBubblewrap, and it reduces the difference between FHS and
non-FHS packages.
'name' is already handled by runCommandLocal.
This fixes a regression introduced in https://github.com/NixOS/nixpkgs/pull/256628
which broke fetching with private = true through a netrc file.
Tested locally with a really special github enterprise.
> If using a target spec JSON file, the <triple> value is the filename
> stem. For example --target foo/bar.json would match [target.bar].
- https://doc.rust-lang.org/cargo/reference/config.html#target
I've also exposed toRustTargetSpecShort as a public function, because
it's useful to be able to know what the target subdirectory will be.
This function helps building an OCaml package that builds with topkg.
There are currently many such packages in nixpkgs and this function
would greatly simplify adding more.
This is heavily inspired by `ocamlPackages.buildDunePackage`.
This initially may look like a downgrade, but this is caused by how
upstream is tagging versions.
Before they would have the GraalVM having its own version (e.g. 22.3.1),
and each version would support multiple JVM versions (e.g. 11, 17, 19).
Now each release supports only one JVM version (e.g.: 21), and they
track the same version as the JVM.
They also changed packaging, making all sub-products (e.g.: GraalPy,
GraalRuby, etc.) standalone, so they do not depend in GraalVM anymore
and have their own version. Thanks to this change, we will need to
repackage everything.
To simplify, this commit will remove all sub-products and only care
about the GraalVM/Native Image (that is back to GraalVM itself) part.
Other commits will re-added each sub-product.
Fix (partial): https://github.com/NixOS/nixpkgs/issues/257292
Currently there is a state of severe confusion in
pkgs/build-support/rust/hooks/ regarding host vs target; right now
there is only "host" defined, but whether it means "host" or
"target" seems to fluctuate.
This commit corrects that, ensuring that all variables come in all
three flavors (build, host, target) and are used consistently with
the nixpkgs convention.
This also fixes the cross-compilation of packages which use
`maturinBuildHook` -- hooks go in `nativeBuildInputs` and are
phase-shifted backwards by one platform, so they need to be careful
about distinguishing between build and host.
Closes#247441
