clang: unknown warning option #1606
Comments
|
Ah, this is not Linux, this is Mac OS. This Apple clang identifies itself as version 7.3.0, while clang trunk is currently 5.0. Since 7.0, it doesn't give any info about which clang version it's based on anymore. I'm already looking into that, but as I'm not a Mac user myself, I probably can't maintain a separate Apple clang version list. Given that every clang was treated as version 4.2.1 until recently, maybe we could just treat every new Apple clang version as the latest version the Apple clang version string contained the actual clang version (3.6 in XCode 6.4)? I guess we don't have access to the operating system used in the m4 scripts easily? |
|
Iterating over the options and try which ones that work is also probably a bit complicated since it doesn't seem to exit or properly signal for unknown warning options, other than that message on stderr and it feels error-prone to grep for that!
It's there in the |
Yes, I think that's a decent default work-around, then we can add support for the specific mac-clangs we know support newer options. The latest mac compiler does support -Wcomma though! My dev mac has the latest OS and xcode installed I think: |
Since 5598b0b, clang -v is used to detect the clang version. The version number was expected to come after the word "version". For Apple clang, this doesn't work as it has its own versioning scheme. The version number is now first searched after the string "based on LLVM". This works for Apple clang before version 7, and also for e.g. Ubuntu's clang up to version 3.7. If it's not found and the version string contains "Apple LLVM version", clang version 3.7 is assumed, which is the version that comes with Xcode 7. Otherwise, the version number is still expected after the word "version", which works for very old Apple clang versions. Note: temporarily changing Apple clang on travis back to debug mode to get that warning again. Ref: https://trac.macports.org/wiki/XcodeVersionInfo Fixes curl#1606
Since 5598b0b, clang -v is used to detect the clang version. The version number was expected to come after the word "version". For Apple clang, this doesn't work as it has its own versioning scheme. The version number is now first searched after the string "based on LLVM". This works for Apple clang before version 7, and also for e.g. Ubuntu's clang up to version 3.7. If it's not found and the version string contains "Apple LLVM version", clang version 3.7 is assumed, which is the version that comes with Xcode 7. Otherwise, the version number is still expected after the word "version", which works for very old Apple clang versions. Note: temporarily changing Apple clang on travis back to debug mode to get that warning again. Ref: https://trac.macports.org/wiki/XcodeVersionInfo Fixes curl#1606
Since 5598b0b, clang -v is used to detect the clang version. The version number was expected to come after the word "version". For Apple clang, this doesn't work as it has its own versioning scheme. The version number is now first searched after the string "based on LLVM". This works for Apple clang before version 7, and also for e.g. Ubuntu's clang up to version 3.7. If it's not found and the version string contains "Apple LLVM version", clang version 3.7 is assumed, which is the version that comes with Xcode 7. Otherwise, the version number is still expected after the word "version", which works for very old Apple clang versions. Ref: https://trac.macports.org/wiki/XcodeVersionInfo Fixes curl#1606 Closes curl#1607
|
For future reference, here's a gist with this info: https://gist.github.com/epipping/ef8b02b0cfaec4a5ebf3a57092145a3f by @epipping |
I did this
The Travis CI debug builds on Mac shows a warning that an unknown warning is used:
warning: unknown warning option '-Wcomma' [-Wunknown-warning-option]Example.
I expected the following
No compiler warnings on unknown options used
curl/libcurl version
current git
operating system
Linux
The text was updated successfully, but these errors were encountered: