[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gcc
Subject:    Re: disabling GCC flags at configure time
From:       Richard Sandiford <richard () codesourcery ! com>
Date:       2006-11-29 14:39:57
Message-ID: 87r6vmpb9e.fsf () firetop ! home
[Download RAW message or body]

Basile STARYNKEVITCH <basile@starynkevitch.net> writes:
>> I am thinking of extending the *.opt machinery (ie the
>> gcc/opt-functions.awk gcc/optc-gen.awk gcc/opth-gen.awk files) to
>> offer some GCC options which can be disabled or enabled by an
>> appropriate configure flag.
>> 
>> More precisely, configure can generate HAVE_* and ENABLE_* flags
>> (usually in the gneerated $GCCBUILD/gcc/auto-host.h). My intent is to
>> hack so that the code corresponding to some flags (eg those marked
>> with CppCondition(HAVE_FOO) in common.opt) is conditionally generated
>> with #if defined(HAVE_FOO) && HAVE_FOO!=0 in files
>> $GCCBUILD/gcc/options.c and $GCCBUILD/gcc/options.h
>
> I am a bit ashamed to not have re-read the documentation.  Perhaps the
> Condition() option syntax might be perhaps used. From
> $GCCTOP/gcc/doc/options.texi (file rev119164 from trunk)
>
>   @item Condition(@var{cond})
>   The option should only be accepted if preprocessor condition
>   @var{cond} is true.  Note that any C declarations associated with the
>   option will be present even if @var{cond} is false; @var{cond} simply
>   controls whether the option is accepted and whether it is printed in
>   the @option{--help} output.

Right.

> However, I grepped the source and did not found any use of this in any
> gcc/*.opt file. Does anyone have an idea why this Condition is still
> there?

You need to check the target files too (in gcc/config and subdirectories).
Condition() was added for the SH port.

> And my initial proposal (which I called CppCondition) is slightly
> different (and more general, perhaps safer) If the preprocessor
> condition is false, the C variable for the flag should be not even
> generated. (hence any reference to it will fail at Gcc build time).

We generally want to move away from having preprcoessor conditions
guard code.

Richard
[prev in list] [next in list] [prev in thread] [next in thread]