This commit was created by a combination of scripts and tools:
- an ast-grep script to prefix things in meta with `lib.`,
- a modified nixf-diagnose / nixf combination to remove unused `with
lib;`, and
- regular nixfmt.
Co-authored-by: Wolfgang Walther <walther@technowledgy.de>
After final improvements to the official formatter implementation,
this commit now performs the first treewide reformat of Nix files using it.
This is part of the implementation of RFC 166.
Only "inactive" files are reformatted, meaning only files that
aren't being touched by any PR with activity in the past 2 months.
This is to avoid conflicts for PRs that might soon be merged.
Later we can do a full treewide reformat to get the rest,
which should not cause as many conflicts.
A CI check has already been running for some time to ensure that new and
already-formatted files are formatted, so the files being reformatted here
should also stay formatted.
This commit was automatically created and can be verified using
nix-build a08b3a4d19.tar.gz \
--argstr baseRev 78e9caf153
result/bin/apply-formatting $NIXPKGS_PATH
Currently the target triple leaks into the clang build via llvm using
libbfd, whose build varies according to the target triple.
LLVM only uses libbfd to enable LTO via the linker plugin (called
LLVMgold.so, though multiple linkers can use the same plugin).
Drop the dependency on the libbfd build, and consume the only needed
source instead. (This would be a good use of CA-derivations FWIW).
The result of this commit is that these match:
* nix eval --raw nixpkgs#clang.cc
* nix eval --raw nixpkgs#pkgsStatic.pkgsLLVM.stdenv.cc.cc
* nix eval --raw nixpkgs#pkgsCross.aarch64-multiplatform.pkgsLLVM.stdenv.cc.cc
This means fewer clang builds will be needed to support cross
configurations, and users wanting to target an exotic cross
configuration should be able to do so without a rebuild of clang.
Also drops libbfd.hasPluginAPI which no longer has any users.
Signed-off-by: Peter Waller <p@pwaller.net>
I got the plugin API support at least once incorrect. Instead of
copying the deifnition let's consolidate it within binutils itself.
While at it forward-ported changes to llvm_{13,14,15}.
The change is a no-op from rebuild perspective.
A few potentially disruptive changes:
- binutils does not embed ${binutils-unwrapped}/lib as a default library
search path anymore. This will cause link failures for -lbfd -lopcodes
users that did not declare their dependency on those libraries. They
will need to add `libbfd` and `libopcodes` attributes to build inputs.
- `libbfd` and `libopcodes` attributes now just reference
`binutils-unwrapped.{dev,lib}` pair of attributes without patching
`binutils` build system.
We don't patch build system anymore and use multiple outputs out of
existing `binutils` build. That makes the result more maintainable: no
need to handle ever growing list of dependencied of `libbfd`. This time
new addition was `libsframe`.
To accomodate `out` / `lib` output split I had to remove `lib` -> `bin`
backreference by removing legacy lookup path for plugins.
I also did not enable `zstd` just yet as `nixpkgs` version of `zstd`
package pulls in `cmake` into bootstrap sequence.
Changes: https://lists.gnu.org/archive/html/info-gnu/2023-01/msg00003.html
Without the change cross-compiling libbfd fails as:
GEN doc/bfdver.texi
CCLD doc/chew.stamp
...-bash-5.1-p16/bin/bash: line 1: gcc: command not found
Tested on `pkgsCross.riscv64.libbfd`.
Having all 3 of binutils, libbfd, libopcodes in one directory eases
copying of the whole directory when we need to hold back old version of
the whole of binutils or of it's pieces.
