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