On Apr 17, 2022, at 02:54, Paul Eggert wrote: > On 4/16/22 20:28, Jeffrey Walton wrote: >> maybe you should define a couple of macros >> like GNULIB_LLVM_CLANG_VER and GNULIB_APPLE_CLANG_VER > > I hope we don't need to do that. This is software archaeology (Mac OS X > 10.7.5 is so old that neither the Subject: line nor my patch got its name > right, and nobody mentioned the mistake :-) and these macros would clutter > the code for little benefit. Most Clang-specific code nowadays shouldn't use > Clang version numbers; it should use __has_builtin etc.
I agree you should detect features if you can. If you can't, and you need to look at the compiler version, you need to first establish whether you're using Apple Clang or open source clang, since the two use different version numbering schemes. If __clang__ is defined and __apple_build_version__ is defined, you're using Apple Clang and you could inspect that constant directly or you could look at __clang_major__, __clang_minor__, and/or __clang_patchlevel__ interpreted as Apple Clang version numbers. If __clang__ is defined and __apple_build_version__ is not defined, you're using open source clang and can look at the __clang_*__ defines interpreted as open source clang version numbers. Some sample output from my system: $ clang -dM -E - < /dev/null | egrep '__(clang|apple)' #define __apple_build_version__ 4250028 #define __clang__ 1 #define __clang_major__ 4 #define __clang_minor__ 2 #define __clang_patchlevel__ 0 #define __clang_version__ "4.2 (clang-425.0.28)" $ clang -v Apple LLVM version 4.2 (clang-425.0.28) (based on LLVM 3.2svn) Target: x86_64-apple-darwin11.4.2 Thread model: posix $ xcodebuild -version Xcode 4.6.3 Build version 4H1503 $ sw_vers ProductName: Mac OS X ProductVersion: 10.7.5 BuildVersion: 11G63
