mailing list archives
Re: cmake giving options the compiler does not understand
From: Joerg Mayer <jmayer () loplof de>
Date: Sun, 5 Jan 2014 00:01:10 +0100
On Sat, Jan 04, 2014 at 12:17:35PM -0500, Jeff Morriss wrote:
It's highly unlikely that this directory was previously used with a
compiler that *did* support it (unless Fedora pushed out a compiler
downgrade) but I suppose it is possible.
I don't know. On my (32-bit) system, both compilers correctly report that
it is not supported. I'd need to see the cmake output on a system that
Unfortunately the evidence is all gone now. Maybe if I hit the problem
again in the future...
Ah, OK, I found a way to reproduce it (in current SVN):
1) rm -rf _cmake_build
2) mkdir _cmake_build && cd _cmake_build
3) vi ../CMakeLists.txt
4) Move the "-Wshorten-64-to-32" flag from where it is in the file
to just after "-Wshadow"
5) cmake ..
6) make # just to show that it works (I stopped the build after a
few C files were compiled)
7) vi ../CMakeLists.txt
8) Put "-Wshorten-64-to-32" back where it was (at the end of
9) cmake ..
10) make # now it doesn't work, complaining that
"-Wshorten-64-to-32" is an unknown option
--> It seems cmake isn't caching the result of the test but rather
the value of the variable we're storing the result in (e.g.,
OK, I still tend to regard this as a caching problem. It also looks like
an unusual use case what you are doing. What prompted you to do that?
Joerg Mayer <jmayer () loplof de>
We are stuck with technology when what we really want is just stuff that
works. Some say that should read Microsoft instead of technology.
Sent via: Wireshark-dev mailing list <wireshark-dev () wireshark org>
mailto:wireshark-dev-request () wireshark org?subject=unsubscribe
Re: cmake giving options the compiler does not understand Peter Wu (Jan 02)
- Re: cmake giving options the compiler does not understand, (continued)