`libuuid` is actually a dependency of the host platform and
should not be tucked in `depBuildBuild`.
Also, we don't need `buildPackages.util-linux` for the compilation.
And also the following refactoring:
hare:
1. Replace `NIX_BUILD_TOP` usage with `mktemp`
2. Enable parallel building
3. Get rid of `config-template.mk`, by using `makeFlagsArray` instead
4. Move `wrapProgram` call to `postFixup`
5. Set the `LOCALVER` environment variable to `nix`, so that the `hare
version` command outputs `dev-nix`[1]
6. Set `meta` attribute `mainProgram`
7. Make the package accessible through `all-packages.nix` instead of
`aliases.nix`
8. Move package path from `pkgs/development/compilers/hare/hare` to
`pkgs/development/compilers/hare`, since the scope is now made at
`pkgs/top-level/hare-packages.nix`
harec:
1. Remove `hardeningDisable = [ "fortify" ];`, since both harec and hare
compile normally with it enabled
2. Enable parallel building
3. Set `meta` attribute `mainProgram`
4. Make the package accessible through `all-packages.nix` instead of
`aliases.nix`
5. Move package path from `pkgs/development/compilers/hare/harec` to
`pkgs/development/compilers/harec`, since the scope is now made at
`pkgs/top-level/hare-packages.nix`
harePackages:
1. Move hare packages scope from
`pkgs/development/compilers/hare/default.nix` to
`pkgs/top-level/hare-packages.nix`
2. Remove `hare` and `harec` from `aliases.nix`, moving them to
`all-packages.nix`
3. Change the `callPackage` argument in `all-packages.nix` from
`../development/compilers/hare` to `./hare-packages.nix`
[1]: 1048620a7a/item/scripts/version (L2)
Co-authored-by: starzation <nixpkgs@starzation.net>
for hygiene
Run `deadnix . --edit`
`gccForLibs` is an argument used by multi.nix but it's an argument to
cc-wrapper, not to llvmPackages.
`@args` in `llvm/default.nix` was accidentally added in 4badff49fd
There are no uses of `@` therefore these changes are safe.
Part of ZHF for 23.11: https://hydra.nixos.org/build/241300457
I bisected this failure to this first bad commit: [9ed7bfe46b] llvmPackages: 11 -> 16 on Linux,
then looked around for other repairs made to assuage LLVM's errors. This appears to be the pattern.
While using very old compilers is a fair usecase, it induces a maintenance churn as
we collect more and more LLVM versions for the LLVM maintainers.
Especially when we need to backport uniform changes to the whole tree,
furthermore, it consumes and waste CI resources.
