Bengt Richter <bokr@bokr.com> writes:

>> Why would we want to know whether a package build process has a problem
>> with that particular variable?
> Debugging unexpected results?

As fun as that is, I think we have enough things to debug already!  :-)

> I was reacting to
> ┌───────────────────────────────────────────────────────────────────────────────┐
> │ > >> > Should we unset NOCONFIGURE afterwards?  Probably at least one package │
> │ > >> > uses this variable for something completely different...               │
> │ > >>                                                                          │
> │ > >> It probably wouldn't hurt to unset it. I've never come across a package  │
> │ > >> where that's been a problem but best not invite trouble.                 │
> └───────────────────────────────────────────────────────────────────────────────┘
> and wondering what kind of problem was anticipated if NOCONFIGURE were left set.
>
> So I thought, if you unset it, you will never discover that problem.
> Then I doubled down with the rest, to suggest forcing the ghost problem
> to show itself ;-)

Right.  While I generally agree with the sentiment, in this case, by the
time we discovered any problem it would be too late to fix!  Because
changing gnu-build-system entails a full rebuild we have to be extra
careful with what goes on in there.

> My motivation was to make any problem more easily debuggable rather than less,
> but it was about debugging, not standard operating procedure.

To me it's also about purity: the purpose of NOCONFIGURE is to work
around some corner cases with the typical "bootstrap" scripts found in
Autotools projects.  Thus it is really not useful outside of the
'bootstrap' phase, unlike say PATH, which is also set by
gnu-build-system.