This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: PATCH (trunk rev.119231): ability to disable an option at configure time


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
option.

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.

Thanks,
Andrew Pinski


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]