Re: [RFC] Use .opt for the SPARC port

[Richard Sandiford <rsandifo at redhat dot com>]

Eric Botcazou <ebotcazou@libertysurf.fr> writes:
>> Here's the sort of thing I had in mind.  Does it look OK to you?
>> I tested it by changing mips.opt to use the new record type and
>> verifying that it had no effect on the options.h output.
>
> The nice thing with my approach is that masks are almost like options, in 
> particular you can put the same textual description in the .opt file.

But what happens to this textual description?  As I understand it,
it doesn't get copied anywhere outside the .opt file.  If you just
want to describe the meaning of the mask in the .opt file, why not
not add a comment using "; ..."?

>> I agree about the consistency thing though.  It might be better to
>> define _all_ target masks this way.  We could then remove the double
>> meaning of Mask(...) property and also remove the slightly-controversial
>> MaskExists thing.
>
> I don't like this very much, because there would be 2 places to keep in sync 
> for every option.  Self-contained option records are better I think.

Fair enough.  Like you say, it saves me from work ;)

> So I propose the following compromise:
>
> @item
> A target mask record.  These records have three fields: the
> string @samp{TargetMask}, a Mask(@var{name}) declaration and
> an optional textual description.  The options-processing script will 
> automatically allocate a unique bit in the @code{target_flags} variable
> (@pxref{Run-time Target}) and set the macro @code{MASK_@var{name}} to the
> appropriate bitmask.  It will also declare a @code{TARGET_@var{name}}
> macro that has the value 1 when the option is active and 0 otherwise.
> The textual description serves only as a comment.

Again, I don't see what this gains over my proposal.  Why force
there to be a third field if it's ignored?  .opt files now serve
as the declaration point for target masks so I don't see what's
wrong with using comments in those files to document the masks.

Richard