makeWrapper: Remove unused extraFlagsArray feature

[chkno]

Motivation for this change

There is a bug in this feature: It allows extra arguments to leak in
from the environment. For example:

$ export extraFlagsArray=date
$ man ls

Note that you get the man page for date rather than for ls. This happens
because man happens to use a wrapper (to add groff to its PATH).

An attempt to fix this was made in 5ae1857 in PR #19328 for
issue #2537, but 1. That change didn't actually fix the problem because
it addressed makeWrapper's environment during the build process, not the
constructed wrapper script's environment after installation, and 2. That
change was apparently accidentally lost when merged with 7ff6eec.

Rather than trying to fix the bug again, we remove the extraFlagsArray
feature, since it has never been used in the public repo in the ten
years it has been available.

wrapAclocal continues to use its own, separate flavor of extraFlagsArray
in a more limited context. The analogous bug there was fixed in
4d7d10d in 2011.

Things done

• Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS)
• Built on platform(s)
  • NixOS
  • macOS
  • other Linux distributions
• Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
• Tested compilation of all pkgs that depend on this change using nix-shell -p nix-review --run "nix-review wip"
  • Tested compilation of all pkgs that depend on this change that are installed on my machine -- about 1000 packages
• Tested execution of all binary files (usually in ./result/bin/)
  • Ran my personal computer with this change for a week
• Determined the impact on package closure size (by running nix path-info -S before and after)
• Ensured that relevant documentation is up to date
• Fits CONTRIBUTING.md.

[veprbl]

The feature in question was introduced in e01be47

[chkno]

Fixed commit description: "seven years" -> "ten years".

[globin]

Could you base this on the staging branch, please.

[chkno]

Switched to staging.

[globin]

@GrahamcOfBorg eval

[veprbl]

Eval issue should be resolved now
@GrahamcOfBorg eval

[arcnmx]

This just hit unstable yesterday and I use this pretty frequently, what is the recommended replacement? Something like --run 'set -- --something "$@"' maybe?

[chkno]

@arcnmx - Can you share an example of how you use it?

[arcnmx]

Hm mostly things like this and set does work fine. To be fair using run like that is probably an indicator that it's worth using an actual/custom wrapper anyway.

[chkno]

Cool, looks like you found a way to proceed. Sorry to cause you some churn.

Yes, it looks like --run 'set -- YOUR ARGS HERE "$@"' works as a general replacement for --run 'extraFlagsArray=(YOUR ARGS HERE)', and one that doesn't cause trouble for simpler uses of makeWrapper and wrapProgram the way extraFlagsArray did.

It looks like your wrappers end up coming out something like:

#! /nix/store/...-bash/bin/bash -e
export RUSTC_SYSROOT=${RUSTC_SYSROOT-'blah'}
[[ -z $RUSTC_SYSROOT || $* = *--sysroot* ]] || set -- --sysroot "$RUSTC_SYSROOT" "$@"
[[ -z $RUSTC_TARGET || $* = *--target* ]] || set -- --target "$RUSTC_TARGET" "$@"
[[ -z $RUSTC_FLAGS ]] || set -- $RUSTC_FLAGS "$@"
exec -a "$0" "/nix/store/.../bin/rustc" "$@"

This allows RUSTC_FLAGS from the wrapper's runtime environment to leak into the invocation of rustc, which in this case is both exactly what you want and exactly what it says on the tin -- it is not a surprise that RUSTC_FLAGS get passed to rustc.

Thanks for sharing your impact & fix!