If I have the time to look at this in depth, I'll create a branch, but the task is open to any other volunteers... My impression was that there could be quite a few cases to handle beyond LIBS in cmake.

Dash appears to have -u , from 'info dash':

          -u nounset       Write a message to standard error when attempting to expand a variable that is not set, and if the shell is not interactive, exit
                            immediately.

but doesn't seem to have -o pipefail .

So -u should be usable for basic.mk - but obviously will have to be tested properly first.

See https://savannah.nongnu.org/task/index.php?15997 for safe-rm , an alternative to set -u for reducing the chance of a catastrophic rm event.

The command help set shows two potentially very useful bash options for reducing the chance of catastrophic errors (recursive remove due to an "unbound" (undefined) environment variable) and for failing a pipe if any of the pipe elements fails, rather than continuing on happily despite the error. There's a very nice explanatory cartoon at [1].

We already have 'set -x'. The other two options are:

-u Treat unset variables as an error when substituting.

and

-o
             pipefail     the return value of a pipeline is the status of
                           the last command to exit with a non-zero status,
                           or zero if no command exited with a non-zero status

I tried setting both in reproduce/software/make/high-level.mk . One easy bug which was probably OK to fix was that the cmake rule defined LIBS in terms of "$$LIBS ...". This failed with -u because LIBS was "unbound". My guess is that we don't need any external values in LIBS, so this could easily be fixed to remove the "old" $$LIBS.

However, then on a successive ./project configure --existing-conf command I got several fatal failures because of some unbound variables, apparently related to previously installed (or not yet installed?) packages.

My guess is that including both of these options in high-level.mk and initialize.mk would be useful in the long run, in addition to set -e, making the overall system more robust and secure, but some time would first have to be invested in fixing things that break as a result. Most are probably easily fixed, and probably should be fixed.

[1] https://octodon.social/@eptf/105080666953522366