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

[Basile STARYNKEVITCH]

Le Sun, Nov 26, 2006 at 05:59:59PM -0500, Daniel Jacobowitz écrivait/wrote:
> On Sun, Nov 26, 2006 at 02:56:30PM -0800, Andrew Pinski wrote:
> > 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.
> 
> I agree; I don't think we should be making this distinction.  If an
> option isn't compiled in for some reason (e.g. because an external
> library was missing), we should still recognize the option so that we
> can give a sensible error message.

A big thanks to Daniel Jacobowitz & Andrew Pinski for your
constructive comments. What bothers me a little bit is that some
conditional options have their flag variable (like flag_tree_ccp or
ix86_asm_string) still declared in the generated options.h but I think
it would be safer if it was not declared when the feature is disabled
at configure time. Of course we could add somewhere a

  #if !defined(ENABLE_FOO) || !ENABLE_FOO
  #define flag_foo   @@@flag foo undefined here@@@
  #endif

but I would still prefer that the awk scripts generated something like
  #if defined(ENABLE_FOO) && ENABLE_FOO
  int flag_foo;
  #endif 

in the generated options.h - the advantage is to catch some errors
(like the use of flag_foo in a context where --disable-foo has been
configured) at compile time; it is ok to me to leave the foo option
elsewhere (ie in options.c and the help)). To have only options.h
changed, just use the gcc/opth-gen.awk hunk in
http://gcc.gnu.org/ml/gcc-patches/2006-11/msg01769.html and drop the
gcc/optc-gen.awk hunk. (If you are interested tell me to resubmit it).

Actually, the feature I might dream of is a compiler probe that I
started discussing on http://gcc.gnu.org/ml/gcc/2006-11/msg00819.html

Thanks for reading.

PS. Should I suppose that readers of gcc-patches@ subscribe to gcc@ or
not? Should I discuss ideas on gcc-patches@ or only on gcc@?

-- 
Basile STARYNKEVITCH         http://starynkevitch.net/Basile/ 
email: basile<at>starynkevitch<dot>net mobile: +33 6 8501 2359 
8, rue de la Faïencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***