This is the mail archive of the fortran@gcc.gnu.org mailing list for the GNU Fortran 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: How to create both -option-name-* and -option-name=* options?


On 10 November 2006 21:18, Brooks Moses wrote:

> Dave Korn wrote:

> But that's already not possible -- that's essentially how I got into
> this problem in the first place.  If one tries to define both of those,
> the declaration of the enumeration-type holding the option flags breaks,
> so you can't do that.

  That aside, it would have been possible before, and the mangling could
easily have been fixed to support it had we wanted to.

> (Well, you could hack that to make it work; define -fFLAG as the option
> name, so that the '-' or '=' is the first character of the argument.
> That will still work, but it's a pain if VALUE is otherwise a UInteger.)

  Yeh, but it's also the right thing to do with the machinery as it stands.
 
> This does raise a point about how the options are compared, though -- to
> be useful, this needs to also handle cases where a Joined option is
> emulated by a "normal" option.  For instance, Fortran's lang.opt
> contains something like:
> 
>    -ffixed-line-length-none
>    Fortran
> 
>    -ffixed-line-length-
>    Fortran Joined
> 
> We would also want "-ffixed-line-length=none" to be handled
> appropriately, which makes this a bit trickier than just handling the
> last character of Joined options.
> 
> Are there any meaningful downsides to just having the option-matcher
> treat all '-' and '=' values in the option name as equivalent?  It would
> mean that we'd also match "-ffixed=line=length-none", for instance, but
> I don't think that causes any real harm.

  I think it's horribly ugly!  (Yes, this would not be a show-stopper in
practice; I have a more serious reason to object, read on...)

> An alternative would be to specify that an '=' in the name in the .opt
> file will match either '=' or '-' on the command line.  This does
> require that the canonical form be the one with '=' in it, and means
> that things with '-' in them need to be changed in the .opt file to
> accept both, but the benefit is that it can accept pseudo-Joined options
> in either form without accepting all sorts of wierd things with random
> '='s in them.

  I think that for this one case we should just say that you have to supply
both forms -ffixed-line-length-none and -ffixed-line-length=none.

  What you have here is really a joined option that has an argument that can
be either a text field or an integer, and to save the trouble of parsing the
field properly you're playing a trick on the options parser by specifying
something that looks to the options machinery like a longer option with a
common prefix, but looks to the human viewer like the same option with a text
rather than integer parameter joined.

  Treating a trailing '-' as also matching a '=' (and vice-versa) doesn't blur
the boundary between what are separate concepts in the option parsing
machinery.  I think if you really want these pseudo-joined fields, add support
to the machinery to understand that the joined field can be either a string or
a numeric.

  The change I'm proposing is kind of orthogonal to that.  It solves your
problem with the enum; there becomes only one enum to represent both forms and
both forms are accepted and parse to that same enumerated value.  It does not
solve nor attempt to address your other problem, with the limitations on
parsing joined fields, and I don't think we should try and bend it into shape
to do this second job as well.

  If you address the parsing limitation on joined fields, the flexibility that
my suggestion offers /will/ automatically be available to your usage.


    cheers,
      DaveK
-- 
Can't think of a witty .sigline today....


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