On 11 November 2006 00:14, Brooks Moses wrote:
> Dave Korn wrote:
>> On 10 November 2006 21:18, Brooks Moses wrote:
>> 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.
Oh of couse. Hey, isn't this where I came in?
>> 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".
All the more reason to give the option parser even more useful things that
it does that can be leveraged.
> 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".
Your choice; there's only a limited need to support ancient compile flags.
Actually, perhaps you should fix this simply, by using a specs to rewrite
the =none version into the -none version. Is there not a Fortran equivalent
of CC1_SPEC/CC1PLUS_SPEC/... ?
cheers,
DaveK
--
Can't think of a witty .sigline today....