From mboxrd@z Thu Jan 1 00:00:00 1970 From: toddpw@ugcs.caltech.edu (Todd P. Whitesel) To: mlist-egcs@nntp-server.caltech.edu Subject: Re: Require GNU Make Somehow? Date: Sat, 02 May 1998 01:35:00 -0000 Message-id: <6ielrl$2em@gap.cco.caltech.edu> References: X-SW-Source: 1998-05/msg00030.html Craig Burley 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} gnu_sed gnu_bash gnu_grep ./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