Re: Require GNU Make Somehow?

[toddpw@ugcs.caltech.edu (Todd P. Whitesel)]

Craig Burley <burley@gnu.org> writes:

>Guess I have a bit of a belt-and-suspenders mindset towards safety,
>plus a vivid imagination when I get bug reports from people who
>see buggy behavior in g77 on configurations almost exactly identical
>to mine, but I can't reproduce the problem at all, since, often,
>when it is finally learned what the problem is, it's a very subtle
>configuration or library mismatch problem that stemmed from some
>kind of build problem.

I have a lot of sympathy for this viewpoint. I have been burnt time and
time again by programs that outsmarted themselves trying to figure out
what I want so they could keep going and only obscure the error when it
finally fails hard. What I _want_ is for them to stop dead with an error
message that points directly at something in my source or build directory.

At my previous job there were a few of us who periodically sanitized
source directories to localize the places where configuration-dependent
things were stored. These few places were well publicized and were easy
to grep through or even browse manually. I could teach new employees how
to diagnose and fix most port-related bugs in about a day. This would
happen acceptably often because of people throwing in time/date code or
yet another directory slash piece of code; we'd drag it over to the
"toxic code dump" modules, and either fix it outright or leave asserts and
comments in it for the next guy. I can't vouch for the rest of the product
however -- this was Green Hills MULTI.

This scheme worked well because it was easy to communicate to new people what
to do when they ran into a problem, and new ports were much easier because
95% of what you changed was next to something else you'd have to change. We
accepted the inevitability of configuration bugs and made it a priority to
ensure that diagnosis and treatment of those bugs was fairly obvious.

So far I have found that configure is largely the opposite. If it does not
just work, then your chances of finding the problem are largely dependent
upon your ability to simulate bash scripts in your head. Eventually you get
enough of an idea what's going on in there and you can fix things without
going for primal scream therapy -- after which you tolerate configure and
even learn to admire it, but the fact remains that you've now joined the
ranks of the priesthood, and will be forever different from the other kids.

Could we have some kind of paranoid configure mode that did this for, say, gdb:

    $CC ${srcdir}/gmake/*.c -g -o ./gnu_make
    ./gnu_make CC=$CC SRCDIR=${srcdir} <etc.> gnu_sed gnu_bash gnu_grep <etc.>
    ./gnu_bash configure
    ./gnu_make all-gdb

For bootstrapping on a system with suspect /bin programs but a passable cc,
this would eliminate a lot of the unknowns. Once it's available to people it
can be used as a standard "sanity check" to determine if it's your system or
the GNU source tree that is having problems.

Todd Whitesel
toddpw @ ugcs.caltech.edu