[PATCH] Make the driver accept all four variants of the target option

[Renato Golin]

Hi James,

getopt is a good argument. I lift my restrictions. Please wait for
other Clang folks opine on the validity of this.

cheers,
--renato

On 19 February 2015 at 15:12, James Molloy <james at jamesmolloy.co.uk> wrote:
> Hi Renato,
>
> I disagree with you about there being consensus in the UNIX world about
> this. Taken from the manpage of getopt_long:
>
>> A long option may take a parameter, of the form --arg=param or --arg
>> param.
>
> if getopt(3) accepts it, there doesn't seem to be consensus that it should
> be rejected. I agree with Gabor and Richard (without having conferred
> beforehand) that it's mega confusing and has been a pain point for a while.
>
> Cheers,
>
> James
>
> On Thu Feb 19 2015 at 1:32:01 PM Renato Golin <renato.golin at linaro.org>
> wrote:
>>
>> In http://reviews.llvm.org/D7730#126353, @richard.barton.arm wrote:
>>
>> > Point taken, but there are counterexamples. A very quick play in my
>> > terminal shows that diff accepts the option --ifdef with either a space or =
>> > separating the argument. Same for grep and --exclude, emacs and
>> > --cursor-color.
>>
>>
>> If the others are not following the "standard", let's not break what is.
>>
>> > -mcpu=, -fdiagnostics-color= are both valid.
>>
>>
>> These are GCC's fault, there isn't much we can do.
>>
>> > --mhwdiv is available as --mhwdiv=arm, --mhwdiv arm and -mhwdiv=arm, but
>> > not as -mhwdiv arm!
>>
>>
>> I'd remove the non-conforming options. How does GCC behave in those cases?
>>
>> > "Need" is too strong here. Our concern is out-of-box usability to people
>> > unfamiliar with the tool. If a user takes clang and passes --target
>> > arm-none-eabi or -target=arm-none-eabi they get error messages like:
>>
>> >
>>
>> > clang-3.7: error: unsupported option '--target'
>>
>> >  clang-3.7: error: no such file or directory: 'arm-none-eabi'
>>
>> >
>>
>> > or
>>
>> >
>>
>> > clang-3.7: error: unknown argument: '-target=arm-none-eabi'
>>
>> >
>>
>> > which is pretty poor.
>>
>>
>> I agree, but we should fix the error messages, and not add more
>> complexity. We already have infrastructure in Clang to suggest the
>> appropriate syntax, we should use that instead.
>>
>> > It seems to me that given clang is not consistent with its application
>> > of these unix rules and that there are no gcc compatibility issues to
>> > consider, this would be a simple way to improve the situation.
>>
>>
>> We don't "have" to be consistent to anything, we just *want* to be. The
>> ones we chose to follow on Unix systems are the Unix and GCC standards,
>> where it fits. My view is that everything else that is neither, should fit
>> into one or the other.
>>
>> I certainly don't speak for everyone, but for this specific case, I think
>> we should fix the diagnostics on -target, instead of accepting more options.
>>
>> cheers,
>> --renato
>>
>>
>> REPOSITORY
>>   rL LLVM
>>
>> http://reviews.llvm.org/D7730
>>
>> EMAIL PREFERENCES
>>   http://reviews.llvm.org/settings/panel/emailpreferences/
>>
>>
>>
>> _______________________________________________
>> cfe-commits mailing list
>> cfe-commits at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
>
>
> _______________________________________________
> cfe-commits mailing list
> cfe-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
>