this will allow users of `/pkgs/development/compilers/llvm/default.nix`
to introspect the current version of each llvm version. note that this
is only exported from this default.nix, and will only be accessible to
users who callPackage this directly. this new field will not be
reachable from any llvmPackages in nixpkgs's exported packages.
Most eggs in the canonical repository don't declare a `version` property in their `.egg` files. This
is because it's provided implicitly when using `chicken-install` to retrieve them. Quoting from [the
manual](https://wiki.call-cc.org/man/5/Egg%20specification%20format#version):
> Eggs from remote egg servers are automatically versioned - the version is part of the protocol to
retrieve the egg and does not have to be specified in the .egg file.
Since we don't use `chicken-install` to retrieve eggs, this leaves us with a version of "unknown" in
most cases, e.g.:
$ nix-shell -p chickenPackages.chickenEggs.json-abnf chickenPackages.chicken --run chicken-status
abnf ...................................................... version: unknown
iset ...................................................... version: unknown
json-abnf ................................................. version: unknown
lexgen .................................................... version: unknown
regex ......................................................... version: 2.0
srfi-1 .................................................... version: unknown
srfi-127 .................................................. version: unknown
srfi-69 ................................................... version: unknown
utf8 ...................................................... version: unknown
This is usually not an issue unless another egg declares a minimum required version dependency on an
egg with missing version info. In this case, `chicken-install` will fill in "0.0.0" as a fallback
and the check will fail. This has so far been worked around patches (see e.g. #346004 or #358455).
This patch addresses the root cause by following the documentation's recommendation:
> Eggs installed from local directories (see below) should explicitly specify a version.
To do that, `eggDerivation` now simply always adds the version to the generated `.egg-info`
file. This has the added benefit of correcting potentially inconsistent version declarations in
`.egg` files. Note that we cannot patch the original `.egg` file because not all released egg
versions match [the stricter version format validation which currently applies
there](https://bugs.call-cc.org/ticket/1855).
The patch also changes the signature of `eggDerivation` to allow passing in `pname` and `version`
instead of `name` to allow for easy access to the egg version. However, for backwards compatibility,
the old `name` argument is also still supported.
As a result, the aforementioned overrides are removed again and some additional eggs can be marked
as unbroken again.
And finally, this is the output of the above `chicken-status` call with the patch applied:
$ nix-shell -p chickenPackages.chickenEggs.json-abnf chickenPackages.chicken --run chicken-status
abnf .......................................................... version: 8.3
iset .......................................................... version: 2.2
json-abnf ..................................................... version: 7.0
lexgen ........................................................ version: 8.2
regex ......................................................... version: 2.0
srfi-1 ...................................................... version: 0.5.1
srfi-127 ...................................................... version: 1.3
srfi-69 ..................................................... version: 0.4.3
utf8 ........................................................ version: 3.6.3
We also need to symlink libexec when doing fastCross.
It contains rust-analyzer-proc-macro-srv which rust-analyzer needs for proc macro expansion to work.
We can now force terminfo to be built, making the
configuration-ghc-*.nix file for ghcHEAD free of conditionals. Of
course, certain packages won't exist on every platform, e.g. terminfo
won't be available when cross-compiling to Windows. In such situations,
however, depending on the package doesn't make sense anyways so having
it set to `null` should be fine.
Fix version number for the ghc specific configuration. We'll have to
create a new one upon release of GHC 9.14, but there aren't any
overrides beyond core packages in there anyways.
This reverts commit 1dc7345389.
Reason for revert: The change doesn't work as in intended, i.e. hadrian
refuses to build a Stage2 compiler as requested in the “native cross”
case. Thus the canExecute condition only served to confuse
We can safely drop the upper bound for the jailbreak workaround for
directory >= 1.3.9.0 since all GHCs will probably have this constraint
going forward.
