If you want a less intrusive alternative, you could treat NIX_DEBUG as a string of one letter flags, using NIX_DEBUG=x and [[ "${NIX_DEBUG:-}" == *x* ]] to activate set -x. This will not require changing anything beyond stdenv/generic/setup.sh.

As a sidenote, I wrote a Linux tool that proved very useful to debug and inspect all kinds of build problems called fptrace. It supervises a build process and writes a shell script for each program launched during the build. You can examine what environment variables were set, what command line arguments were passed, and repeat any build step, possibly altering it beforehand. The command will look like fptrace -e -rm -s /tmp/fp nix-build -K ….

You may be aware of this, but @dezgeg wrote the great nix-debug-shell that surpassed my need for set -x in the stdenv.

@orivej I didn't know of either of those. Thanks, they look quite useful! There's still a need to debug the code before any the phases (say with all my changes to findInputs in #26805), though, and for this I think set -x is still useful. The two you mention are definitely better for debugging packages most of the time, however :).

We could use a set of flags, but seeing that this is a mass-rebuild no matter what, I don't mind changing all the use-sites: it makes things clearer for the reader.

You may also consider a more generic alternative: to evaluate an arbitrary value in setup.sh, e.g. eval "$NIX_DEBUG_STDENV_SETUP".

I really like your improvements @Ericson2314 - just one request: can we update nixpkgs manual stdenv section to reflect such changes? In this case: https://nixos.org/nixpkgs/manual/#ssec-stdenv-attributes

@domenkozar Did that, and added wrapper script set -x at NIX_DEBUG >= 7.

[Did a little force-push and force-push dance to get github to pickup that the previous PR this was based off of is now merged. That will make the history easier to read for @edolstra, the only person whose opinion this is blocked on.]

@edolstra approved of this on IRC.