How to create both -option-name-* and -option-name=* options?

[Brooks Moses]

Dave Korn wrote:
> On 10 November 2006 21:18, Brooks Moses 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.

Right, yeah -- my point was just that nobody _had_ fixed the mangling to 
support it, and thus that this was only eliminating a theoretical 
possibility rather than something someone might actually be doing, which 
means in practice it's not changing very much.

>>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...)

I think it's horribly ugly, too -- but I don't see that the ugliness 
shows up anywhere unless some user is _intentionally_ doing something 
ugly; it just means that their ugly usage is rewarded by the compiler 
doing essentially what they expect, rather than throwing an error.

>>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.

Which I would be glad to do, except that as far as I can tell, it's not 
possible to actually do that.  The same problem arises there as arises 
when it doesn't have "none" on the end and "Joined" in the specification.

>   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.

Right, agreed.  Though it's not so much "to save the trouble" as "to be 
able to leverage all the useful things the option parser does to verify 
numeric fields".

>   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.

Well, I'm not sure that I "want" them, exactly.  They're only in 
gfortran because we're supporting backwards compatibity going back to 
the very early days of g77.

>   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.

Hmm.  Valid points.

And, given that adding support for both string and numeric values looks 
fairly easy (much more so than I would have guessed), that's probably 
the better way to go.  A UIntegerOrString property would be incompatible 
with the Var property, since it would need two variables for storing the 
result, but I think this is not a notable loss since the combination of 
Var and UInteger is already rare -- the only flag that uses them both is 
-fabi-version.

Or, given that the only thing that appears to use this at the moment is 
this old g77-style fixed-line-length Fortran option that we're only 
supporting for legacy purposes, I suppose we could just go for the 
cop-out of supporting the "-none" version and not the "=none" version, 
and only document it as accepting "=0".

- Brooks