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 <[email protected]> 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 <[email protected]> > 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 >> [email protected] >> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits > > > _______________________________________________ > cfe-commits mailing list > [email protected] > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits > _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
