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

[James Molloy]

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20150219/1cd27f93/attachment.html>