This is the mail archive of the
mailing list for the GCC project.
Re: PATCH (trunk rev.119231): ability to disable an option at configure time
- From: Andrew Pinski <pinskia at gmail dot com>
- To: Basile STARYNKEVITCH <basile at starynkevitch dot net>
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Sun, 26 Nov 2006 14:56:30 -0800
- Subject: Re: PATCH (trunk rev.119231): ability to disable an option at configure time
- References: <20061126224301.GA25585@ours.starynkevitch.net>
On Sun, 2006-11-26 at 23:43 +0100, Basile STARYNKEVITCH wrote:
> The motivation for such a feature is to permit some expensive
> processing in GCC to be enabled or disabled at configure time, and
> when it is enabled, to offer an additional GCC runtime flag which
> triggers it. As a simplistic scenario, the --enable-check=tree
> configure option enable the build of $GCCBUILD/gcc/tree-browser.o
> (which is not even built from $GCCTOP/gcc/tree-browser.c without this
> --enable-check!), this tree-browser.o offers a browse_tree function,
> and we could in that case only propose a -fbrowse-tree flag which
> calls this function at several interesting points in the compiler. If
> configured without any --enable-check the compiler won't even accept
> such a -fbrowse-tree flag
tree-browser is a debugging tool rather than an expensive processing.
It is only callable from inside the debugger and I would hope it stays
that way because it is not a good idea to wait for input with just an
I rather not have the ability to disable an option at configure time.
In fact, this will confuse some users who used one version of GCC and
then go to another machine with that same version but configured
slightly different, get different options.
In fact the reason why we have options in general is to disable
expensive processing and not configure options. Now defaulting to
on/off is a different story but fully disabling an option seems wrong.