r231787 - Allow -target= and --target options

[Richard Barton]

Hi Chandler

 

It turns out that this patch that you objected to never got reverted. 

 

Sorry about that – I have reverted it now as r237003

 

Thanks

Rich

 

From: Chandler Carruth [mailto:chandlerc at google.com] 
Sent: 13 March 2015 07:24
To: Justin Bogner
Cc: Richard Barton; llvm cfe
Subject: Re: r231787 - Allow -target= and --target options

 

 

On Fri, Mar 13, 2015 at 12:14 AM, Justin Bogner <mail at justinbogner.com> wrote:

FWIW, in my experience very few --option style options require '='. This
is almost always optional and a space is accepted instead.

 

Yes, existing command line tools are shockingly bad at being consistent. It's quite frustrating. Even "simple" commandline interfaces like GNU awk are inconsistent. :: sigh ::

 

Anyways, this is part of why I wouldn't suggest consistency as a reason to favor requiring the '='s. I think that requiring the '='s rather than relying on the order of flags is a vastly superior technical approach, especially for a command where we expect complex systems to manage very large numbers of flags composited from many systems (in short, build systems coping with the vagaries of portability across platforms and toolchains). There are too many ways confusion can erupt from an option being separated from its value accidentally. That's my vote anyways, and as you say...

 


That said, we're horribly inconsistent about which option styles we
accept for legacy and compatibility reasons. Adding every possible way
to spell an option will only increase the inconsistency, and I'd really
rather we didn't go there. For our own options we should choose a style
and stick with it.


Exactly. Unless there is some strong reason to prefer the syntax without an '='s, I vote we just require it and try to stick to it. =]

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20150511/590a8024/attachment.html>