Dave Korn wrote:
On 10 November 2006 20:06, Mark Mitchell wrote:
Dave Korn wrote:
It may seem a bit radical, but is there any reason not to modify the
option-parsing machinery so that either '-' or '=' are treated
interchangeably for /all/ options with joined arguments? That is,
whichever is specified in the .opt file, the parser accepts either?
I like that idea.
Would it be a suitable solution to just provide a specialised wrapper around
the two strncmp invocations in find_opt? It seems ok to me; we only want this
change to affect comparisons, we call whichever form is listed in the .opts
file the canonical form and just don't worry if the (canonical) way a flag is
reported in an error message doesn't quite match when the non-canonical form
was used on the command line?
I would think that would be suitable, certainly. Having the error
message report the canonical form would, to me, just be a beneficial
small reminder to people to use the canonical form.
(I'm not even going to mention the 'limitation' that we are now no longer
free to create -fFLAG=VALUE and -fFLAG-VALUE options with different meanings!)
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.
(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.)
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.
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.
- Brooks