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
