Wireshark-dev: Re: [Wireshark-dev] cmake giving options the compiler does not understand
Date Index · Thread Index · Other Months · All Mailing Lists
Date Prev · Date Next · Thread Prev · Thread Next
From: Jeff Morriss <jeff.morriss.ws@xxxxxxxxx>
Date: Sat, 04 Jan 2014 20:14:10 -0500
On 01/04/2014 06:01 PM, Joerg Mayer wrote:

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?
Just looking for a way to reproduce the problem. The idea it was caching the "wrong" thing popped into my head.
I think it explains well why I hit it and why Alexis said he occasionally hits it: when we hit it it's probably because someone reordered the flags.
Could the variable to store the names simply include the compiler option? It doesn't appear that the code relies on them being numbered 1,2,3,4... Well, that doesn't work because it doesn't seem to like the variable name very much:: 


-- Checking for flag: -Wc++-compat
RegularExpression::compile(): Nested *?+.
RegularExpression::compile(): Error in compile.
CMake Error at /usr/share/cmake/Modules/CheckCSourceCompiles.cmake:30 (if):
  if given arguments:

    "WS_C_FLAG_VALID-Wc++-compat" "MATCHES" "^WS_C_FLAG_VALID-Wc++-compat\$"

  Regular expression "^WS_C_FLAG_VALID-Wc++-compat$" cannot compile


Hmmm....