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
> >>has
> >>this problem.
> >
> >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
> WIRESHARK_C_ONLY_FLAGS)
> 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.,
> WS_C_FLAG_VALID39).
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?
Ciao
Jörg
--
Joerg Mayer <jmayer@xxxxxxxxx>
We are stuck with technology when what we really want is just stuff that
works. Some say that should read Microsoft instead of technology.