Compiler detection is flaky and spews errors

[slipher]

The hand-rolled compiler detection from #982 sometimes breaks and prints a lot of errors. Not sure why there are as many as 7 stack traces for only 2 toolchains. It doesn't happen every time; maybe there is some race condition. It is still possible for the build to finish afterward (which is good I guess, but would be bad if we actually needed the result).

The following log is from a MSYS MinGW 64-bit build. But it also happens to me with Linux + GCC + Make, so don't blame Windows.

$ make -j6 nacl-vms
[  0%] Performing configure step for 'nacl-vms'
You can safely ignore the following reported architecture, it is not used.
You can safely ignore the following reported compilers, they are unused.
-- Detected architecture: nacl
-- Enabling nacl architecture intrinsics
-- CMake generator: MSYS Makefiles
CMake Warning at daemon/cmake/DaemonCompiler.cmake:50 (message):
  Failed to build DaemonCompiler.c, relying on CMake builtin detection.
Call Stack (most recent call first):
  daemon/cmake/DaemonCompiler.cmake:192 (detect_daemon_compiler)
  daemon/cmake/DaemonPlatform.cmake:53 (include)
  daemon/CMakeLists.txt:80 (include)


CMake Warning at daemon/cmake/DaemonCompiler.cmake:94 (message):
  Unknown C compiler
Call Stack (most recent call first):
  daemon/cmake/DaemonCompiler.cmake:192 (detect_daemon_compiler)
  daemon/cmake/DaemonPlatform.cmake:53 (include)
  daemon/CMakeLists.txt:80 (include)


CMake Warning at daemon/cmake/DaemonCompiler.cmake:171 (message):
  Unknown C compiler version
Call Stack (most recent call first):
  daemon/cmake/DaemonCompiler.cmake:192 (detect_daemon_compiler)
  daemon/cmake/DaemonPlatform.cmake:53 (include)
  daemon/CMakeLists.txt:80 (include)


-- Detected C compiler: Unknown Unknown pnacl-clang.bat
-- Detected C++ compiler: PNaCl 4.2.1/clang-3.6.0 pnacl-clang++.bat
CMake Warning (dev) at C:/lang/msys2/mingw64/share/cmake/Modules/CMakeDependentOption.cmake:89 (message):
  Policy CMP0127 is not set: cmake_dependent_option() supports full Condition
  Syntax.  Run "cmake --help-policy CMP0127" for policy details.  Use the
  cmake_policy command to set the policy and suppress this warning.
Call Stack (most recent call first):
  daemon/CMakeLists.txt:125 (cmake_dependent_option)
This warning is for project developers.  Use -Wno-dev to suppress it.

-- Enabling compiler intrinsics
-- Enabling compiler custom attributes and operators
-- Detected architecture: nacl
-- Enabling nacl architecture intrinsics
-- CMake generator: MSYS Makefiles
CMake Warning at daemon/cmake/DaemonCompiler.cmake:50 (message):
  Failed to build DaemonCompiler.c, relying on CMake builtin detection.
Call Stack (most recent call first):
  daemon/cmake/DaemonCompiler.cmake:192 (detect_daemon_compiler)
  daemon/cmake/DaemonPlatform.cmake:53 (include)
  daemon/cmake/DaemonGame.cmake:41 (include)
  CMakeLists.txt:72 (include)


CMake Warning at daemon/cmake/DaemonCompiler.cmake:94 (message):
  Unknown C compiler
Call Stack (most recent call first):
  daemon/cmake/DaemonCompiler.cmake:192 (detect_daemon_compiler)
  daemon/cmake/DaemonPlatform.cmake:53 (include)
  daemon/cmake/DaemonGame.cmake:41 (include)
  CMakeLists.txt:72 (include)


CMake Warning at daemon/cmake/DaemonCompiler.cmake:171 (message):
  Unknown C compiler version
Call Stack (most recent call first):
  daemon/cmake/DaemonCompiler.cmake:192 (detect_daemon_compiler)
  daemon/cmake/DaemonPlatform.cmake:53 (include)
  daemon/cmake/DaemonGame.cmake:41 (include)
  CMakeLists.txt:72 (include)


-- Detected C compiler: Unknown Unknown pnacl-clang.bat
-- Detected C++ compiler: PNaCl 4.2.1/clang-3.6.0 pnacl-clang++.bat
-- Enabling compiler intrinsics
-- Enabling compiler custom attributes and operators
-- Using CBSE Python executable: C:/lang/msys2/mingw64/bin/python3.10.exe
-- Configuring done (8.3s)
-- Generating done (0.8s)
-- Build files have been written to: C:/lang/msys2/home/dirac/unvb-nacl/nacl-vms
[  0%] Performing build step for 'nacl-vms'
[  0%] Built target srclibs-fastlz
[  4%] Built target srclibs-recast
...

This is a good example of why we should not merge a complex PR like #982 without any code review.

P.S. The messages about compilers/archs "not being used" also seem wrong.

[illwieckz]

Interesting:

  Failed to build DaemonCompiler.c, relying on CMake builtin detection.
-- Detected C compiler: Unknown Unknown pnacl-clang.bat
-- Detected C++ compiler: PNaCl 4.2.1/clang-3.6.0 pnacl-clang++.bat

The C++ compiler detection works while it uses the exact source file as the C compiler detection (it just includes the C source file) and the exact CMake code (it's the same function used for both languages). So this may uncover a stupid bug somewhere.

[illwieckz]

This is a good example of why we should not merge a complex PR like #982 without any code review.

I answered there because I don't want to pollute that thread with that discussion:

• Report what compiler is used to build the game #982 (comment)

I ask to respond on that topic in that other thread if you need to.

[illwieckz]

Here is the fix:

• DaemonCompiler: do not omit main parameter name in C #1506

The cause is that PNaCl doesn't allow int main(int, char**) without parameter names in C. It is probably a matter of default C version, as this is done far before we set our compiler flags.

[illwieckz]

P.S. The messages about compilers/archs "not being used" also seem wrong.

This message was previously intended to be printed before the unused default compiler that is checked uselessly. I guess some other rewrite moved this message in the wrong place, probably that:

• cmake: remove a warning about scope #1468

The root problem of checking compilers multiple times including when being unused when only building VMs is known for a long time and that was the first thing I wanted to fix once the compiler detection code was merged. Unfortunately the compiler detection code merge wasn't done for more than a year and then the proper fix for the root cause was postponed for as much time. I now forgot the relevant knowledge to fix the root cause so I don't know yet when I will be able to fix the root cause.

That message not being in the wrong place anymore can be moved to the right place as a start but a proper fix will still have to be implemented.

[slipher]

I guess the "flakiness" may be that sometimes the NaCl subfolder runs configuration and sometimes not, which gave me the impression of nondeterminism. I still don't get why the number of errors printed is so large though; I have it configured with -DBUILD_GAME_NACL_TARGETS=native so there is only one sub-build.