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?


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


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