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.
Derivations affected by this patch set `__structuredAttrs = true;` and
provide their own `builder`, i.e. it's necessary to `source .attrs.sh`.
Rather than adding even more `if`-`source` monstrums, I decided to
modify all of those derivations to use `buildCommand` or `runCommand`,
without `builder` being set.
Then, `$stdenv/setup` is sourced already and as a result it's safe to
assume that `NIX_ATTRS_JSON_FILE`/`NIX_ATTRS_SH_FILE` point to a usable
location both in a build and a shell session.
When specifying the `builder` attribute in `stdenv.mkDerivation`, this
will be effectively transformed into
builtins.derivation {
builder = stdenv.shell;
args = [ "-e" builder ];
}
This also means that `default-builder.sh` is never sourced and as a
result it's not guaranteed that `$NIX_ATTRS_SH_FILE` is set to a correct
location[1].
Also, we need to source `.attrs.sh` to source `$stdenv`. So, the
following is done now:
* If `$NIX_ATTRS_SH_FILE` points to a correct location, then use it.
Directly using `.attrs.sh` is problematic for `nix-shell(1)` usage
(see previous commit for more context), so prefer the environment
variable if possible.
* Otherwise, if `.attrs.sh` exists, then use it. See [1] for when this
can happen.
* If neither applies, it can be assumed that `__structuredAttrs` is
turned off and thus nothing needs to be done.
[1] It's possible that it doesn't exist at all - in case of Nix 2.3 or
it can point to a wrong location on older Nix versions with a bug in
`__structuredAttrs`.
> 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
