Re: [libstdc++] libstdc++/7691, pass -Wabi, sanity checks

[Phil Edwards <phil at jaj dot com>]

On Wed, Aug 28, 2002 at 09:42:44PM -0700, Benjamin Kosnik wrote:
> > 1)  As noted in PR 7691, --enable-cxx-flags can no longer take multiple
> > options in a quoted string, like it used to, and like the documentation
> > says.  Quoting the argument is now defeated by the higher-level configury
> > at some point; the strings are just passed through too many layers of
> > shell expansion to survive as a single word.
> 
> Hmm. The other option is just having people use CXXFLAGS directly, and
> removing this enable flag.
> 
> ie
> 
> make CXXFLAGS="-fnot-an-idiot -fbigger-magic-wand" all

The advantage to the enable switch is that such flags are remembered
for subsequent rebuilds, if necessary.  (It was originally added to help
rebuild libgcc, back when that was needed.)

I don't have a big problem with removing it altogether.


> > 2)  We now pass -Wabi all the time.
> 
> This is a great idea.

Actually, I might withdraw this part of the patch, and propose passing
-Wabi to all target libraries from the top-level configury.  I need to
test that first though.


> > hasn't worked in a long time, and it's not supposed to work.  This checks
> > to make sure that user isn't massively confused on that point.  I don't
> > know whether we'll continue to release libstdc++ snapshots in the future,
> > but if we do this might help and can't hurt in any case.
> 
> Great idea. I think removing all references to building libstdc++ as a
> standalone package should be removed from the docs, if they are not already.

They've been gone for a long time.

And this part of the patch broke my autobuilder last night.  The assignment

    toplevel_srcdir=\${top_srcdir}/$toprel

embeds the string "$top_srcdir" into the variable, rather than the value
/of/ top_srcdir.  This is because top_srcdir is only an output variable;
it doesn't actually exist during the life of the configure script.

I don't know why it worked when I tested it before.  Good thing it didn't
get checked in after all.


When a user tries to build v3 standalone, the first things that break are
the missing install-sh and config.sub.  What's happened in the past is that
users assume something is broken, find other copies of those files, and copy
them into place.  (!)  If they proceed further, they would be caught by this
explicit no-stop-you're-bring-foolish warning.  (And that's what I tested.)
So if this check doesn't happen after all, they at least have some warning
that something is not right.


Phil

-- 
I would therefore like to posit that computing's central challenge, viz. "How
not to make a mess of it," has /not/ been met.
                                                 - Edsger Dijkstra, 1930-2002