Re: [libstdc++] Add --disable-hosted-libstdcxx, clean up conditionals

[Gabriel Dos Reis <gdr at integrable-solutions dot net>]

Phil Edwards <phil@jaj.com> writes:

| On Thu, Aug 28, 2003 at 09:54:32PM +0200, Gabriel Dos Reis wrote:
| > Bill Wendling <wendling@ncsa.uiuc.edu> writes:
| > | Also sprach Gabriel Dos Reis:
| > | } "Zack Weinberg" <zack@codesourcery.com> writes:
| > | } 
| > | } | Gabriel Dos Reis <gdr@integrable-solutions.net> writes:
| > | } | 
| > | } | Technical limitations of Bourne shell unfortunately have to trump
| > | } | aesthetics.
| > | } 
| > | } Sure.  But, my motivation was not aesthetics.
| > | } 
| > | The "+" is not acceptable in a flag. It's a limitation, as mentioned
| > | above. So the common way to deal with this is to replace + with x. It's
| > | really that simple. This is a valid, well-thoughtout reason why you can't
| > | have + in there.
| > 
| > Did I say the reason Phil enounciated was not valid?  No.  So
| > side-tracking the discussion on that road won't be fruitful.
| 
| Gaby, we were genuinely wondering where you were going with this.
| It's not sidetracking.

Well, it is hard to see where some people were going with eluding
specific, simple, question I asked.  Telling me that something was
done for some reasons does not say much about why that thing is that
way.  It sounds more about "this is not your concern, pass your way".
It is not the kind of answer I was expecting.

| > "+" is not acceptable for a bourne shell variable name, fine.  I don't
| > dispute that simple fact.  It was decided that that "+" should be
| > replaced with "x". That also is fine.  And I don't disupte it.  
| > That conversion may be automated by having sed translate "+" to "x".
| > Should the user-specified be written with the machine oriented name?
| > I think no.  And that is what motivated my request.
| > the option --disable-hosted-libstdc++ flag can be translated to
| > "disable_hosted_libstdcxx" variable name.  There is no innovation
| > there. 
| 
| Aha!  An explanation!
| 
| That's not a bad idea, but it still won't work.  The variable names are
| generated by autoconf, not by us.  Specifically, the problem cases of
| 
|     if test ${foo_libstdc+++set} = set; then
| 
| are all done by autoconf.

ah, now it is not bourne shell limitation, but autoconf limitations :-/
OK, I think I can live with your explanation.  Still, we've being
using tools (in the V3 land) named automake that can just translate
names like libstdc++ to internal canonical names with no hassle. 
We're far from "we can't do that, it won't work". 

| Yes, with sufficient sed wizardry, we could generate 'configure' and then
| do some post-processing before checkin.  That's more trouble than it's
| worth to save the user from typing "configure --help" and learning what
| the spellings are, or from going to the web page where it's all documented.
| It's also a nonstandard procedure for GCC's CVS, and one I would oppose.

I'm sure we can all imagine scenari we ill oppose to for one reason or
the other. 

| > Are you also proposing we should say --enable-languages=cxx instead of
| > the straight --enable-languages=c++?  Atre you also proposinig we
| > rename the compiler from g++ to gxx?
| 
| Not the same thing.

They are all user-written flags.

| None of those names have to be tested by autoconf.

Sure.

| (And we all know that there have been C++ compilers whose names were purely
| alphanumeric for precisely this reason.  It's not uncommon.)

I'm well aware of that.  But not just because some compilers are named
that way we should suddenly rename g++ to gxx.  Should we?

-- Gaby