Basile STARYNKEVITCH <[EMAIL PROTECTED]> 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
