configure.target and a libtoolized mkcheck

[Phil Edwards <pedwards at disaster dot jaj dot com>]

part one:

As a followup to 

    http://sources.redhat.com/ml/libstdc++/2000-11/msg00042.html

I have created a configure.target, moved the major contents
of GLIBCPP_CHECK_OS and GLIBCPP_CHECK_CPU there, and created
GLIBCPP_CHECK_TARGET to take their place.  The actual examination of
configure.target takes place earlier than _OS and _CPU, at the same time
as we examine configure.host.

The .host script got cleaned up a little bit.  Also, since David reminded
me in his followup to the message above, there is a placeholder in
configure.target for future checks against the full target triplet.

I've been using this locally for about a week and haven't seen any
differences from what we're used to.  Comments?  Okay to commit?


part two:

I have re-worked mkcheck.  It's structured a bit cleaner, reports a little
more information, blah blah blah, the point is it uses libtool now.  :-)

At this moment, it also sources configure.target, but nothing's being used
from there (yet), so if y'all think configure.target isn't a good idea,
I'll take that part out before committing mkcheck.in.

The only problem with the libtoolized mkcheck is that hitting ^C doesn't kill
the whole run.  You get a shell prompt back, but the script keeps running.
Changing "libtool" to "echo" restores interruptability, but I don't know
enough about libtool to understand why its trap's are affecting the parent.
(I'm running it, not source'ing it.)

Okay to commit?  I can post the new version if requested (the diff is
larger than the script itself, unsurprisingly).


I should stress that neither of these changes have altered the actual
results of testsuites, etc:  the number of bugs in libstdc++-v3 has
remained constant.

Phil

-- 
pedwards at disaster dot jaj dot com  |  pme at sources dot redhat dot com
devphil at several other less interesting addresses in various dot domains
The gods do not protect fools.  Fools are protected by more capable fools.