Re: [v3] --enable-pch

[Alexandre Oliva <aoliva at redhat dot com>]

On Jul  1, 2003, "B. Kosnik" <bkoz@nabi.net> wrote:

> Geoff, do you have any thoughts on this? I don't think it makes sense to
> disable PCH support in the compiler

Me neither.

> At the same time, I think --disable-pch is pretty clear

Thinking of libstdc++, it surely is.  But the thing to keep in mind is
that, when you configure the top level, you're not configuring only
libstdc++, and the fact that currently libstdc++ is the only project
to support --disable-pch doesn't mean it will always be.  pch means
pre-compiled headers for GCC, but the same top level tree is used for
several other projects, that might have different meanings for pch, or
even that might display different behavior when given this option.
For example, what would you expect --disable-pch do to binutils, or
gdb?  Or even to GCC proper?

I'm just asking for libstdc++-specific configure bits to use a
libstdc++ namespace, to avoid conflicts and overlaps.  If we find that
several different packages are adopting a common idiom, all using
--enable-<package>-<option> for the same effect, we can then consider
adopting a common --enable-<package> that takes a list of packages as
an argument, just like --enable-shared.  But let's not assume that the
meaning of --disable-pch is crystal clear.  I don't think it is.

> renaming it to something else when
> there's nothing else in the tree

What tree are you talking about?  Remember that the top level is not
only GCC.

> Especially when it's documented:

This just means there's one more bit to fix.

> Maybe this documentation just needs to get added to top-level?

Maybe the top-level has to recurse to sub-directories, like autoconf
2.5x's configure --help does?

> ps. Is it --enable-debugging or --enable-debug?

Doesn't really matter.  I don't like either one, for the very same
reasons.

> I would very much like to see the target libraries standardize on
> something, including --enable flag name, installed header locations,
> and installed debug library locations.

This is definitely a desirable goal, but it's not by inventing new
options that might conflict with other packages and then realizing
that even packages in our tree use them differently that we're going
to get there.  We should start by using namespaces for options, see
whether they're sound, and then, if they are, introduce a common
spelling for them such that they can be used for several different
packages.

> The free-for-all with java includes is a bit discouraging.

Ditto for libstdc++ configure options :-)

> FYI, I didn't invent this: I used the same procedure as glibc, which
> IMHO is quite sound.

I don't find glibc's approach clean or sound.  Also, glibc isn't part
of a bigger project that shares the same tree with several other
projects, so it owns the entire configure option namespace, and it's
far from a model to be followed in terms of following GNU
configuration and Makefile construction traditions.

When you asked for my opinion on how to implement --enable-debug, I
didn't reply to the posting you sent to the list, because I was months
behind in the libstdc++ list and only saw it when it was too late; you
pinged me in private, and I replied in private, suggesting you to
model enable/disable debugging as multilibs, instead of as separate
builds in the same directory.  Nothing ever came out of it, other than
this implementation that, should I be following the lists more closely
back then, I'd have objected to.  Since I wasn't, it went in, and I
figured it wasn't fair to bring my objects up so much later.  But now
that new options are going in, I thought it was the time to bring this
issue up and make sure we start following better practices.  I want to
avoid other accidents like libjava and libstdc++ using the same
configure option for different meanings.

Let's please experiment with configure options using names that
reflect the package the option is meant to affect.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                 aoliva@{redhat.com, gcc.gnu.org}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist                Professional serial bug killer