r231787 - Allow -target= and --target options

[Richard Barton]

Hi Chandler, et al.

 

> The vastly more common prefix for these in the rest of the world is '--'. LLVM's usage of '-' is quite strange.

 

Agreed. However, clang seems to have a lot of options that adopt the GCC-style -f<option>[=| ]<argument> format, despite not being real GCC options, and thus having no genuine compatibility concerns. 

 

> I also think there is a strong technical reason to require the '=' -- it makes the relative ordering unimportant. For any tool (such as a build system) which builds up commandline flags, this is a huge advantage.

 

A fair point, but if your build system cannot handle the <option><space><argument> form, are you not going to be in trouble with all the many other clang options that do accept this style? 

 

This feels like an unnecessary line in the sand to me but you have provided decent justification for it so I guess we ought to back this change out.

 

Would you accept a patch to remove support for the legacy alias, so we genuinely do only support one version of this option?

 

Also, could you give some guidance on what these options that must have unambiguous spellings are? AFAICT from the source, it looks like –target, –gcc-toolchain and --driver-mode? Are there others that we should know about?

 

Thanks

Rich

 

From: Chandler Carruth [mailto:chandlerc at google.com] 
Sent: 11 March 2015 21:28
To: Richard Smith
Cc: Richard Barton; llvm cfe
Subject: Re: r231787 - Allow -target= and --target options

 

 

On Wed, Mar 11, 2015 at 2:27 PM, Richard Smith <richard at metafoo.co.uk> wrote:

The previous state was that we allowed -target blah and --target=blah, but not -target=blah nor --target blah. This new state seems better than that in some ways, but neither is particularly satisfactory.


The support for '-target blah' was kept for compatibility with old versions of Clang where folks may have made their build systems rely on it.

 

We probably should have some marking in the .td file for options that are purely for historical compatibility (as opposed to cross-tool compatibility) and sunset them after an appropriately long timeframe.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20150312/fd74e533/attachment.html>