On Jul 15, 2013, at 6:28 PM, Joerg Mayer <jmayer@xxxxxxxxx> wrote:
> On Sun, Jul 14, 2013 at 12:39:26PM +0000, tuexen@xxxxxxxxxxxxx wrote:
>> http://anonsvn.wireshark.org/viewvc/viewvc.cgi?view=rev&revision=50576
>>
>> User: tuexen
>> Date: 2013/07/14 05:39 AM
>>
>> Log:
>> Don't use compiler options not supported by clang in XCode 4.6.3
>> on Apple platforms.
>>
>> Directory: /trunk/
>> Changes Path Action
>> +8 -4 CMakeLists.txt Modified
>
> Weird that this should be necessary: All of these options are tested whether
> the compiler doesn't choke on them and only included if there is no problem.
The only place where we explicitly say "don't use this on OS X" in the autofoo stuff is -Wno-deprecated-declarations, and that's in there to tell the compiler to shut up about the Kerberos library being deprecated, because We're A Cross-Platform Application And Don't Care Whether Apple Would Prefer That You Use Their Frameworks.
*However*, for clang:
you need to specify -Werror=unknown-warning-option when compiling in order to get unknown -W options to fail, rather than just to whine, ignore the option, and continue anyway;
you need to specify -Werror when compiling in order to get unknown -f options to fail, rather than just to whine, ignore the option, and continue anyway.
There's a steaming heap of autofoo to handle that; if CMake isn't handling that itself, we need to arrange that:
we add -Werror=unknown-warning-option to the compiler options used by CHECK_C_COMPILER_FLAG() if compiling a valid warning-free test program with "-Wxyzzy-this-will-never-succeed-xyzzy" doesn't fail;
we add -Werror to the compiler options used by CHECK_C_COMPILER_FLAG() when we're checking an option that begins with -f.
So that *might* be causing CMake not to recognize that those options don't work with clang, because "don't work" doesn't mean "cause clang to fail to compile", it means "causes clang to compile and whine about the invalid compiler option".