[CMake] ExternalProject sometimes fails due to cmTryCompileExec

[Tyler]

Most of the time, when I build a CMake ExternalProject as part of my
larger build, everything works fine:

2>------ Build started: Project: lore_3rdpartylibs_qslog,
Configuration: Release x64 ------
2>Creating directories for 'lore_3rdpartylibs_qslog'
2>No download step for 'lore_3rdpartylibs_qslog'
2>No patch step for 'lore_3rdpartylibs_qslog'
2>No update step for 'lore_3rdpartylibs_qslog'
2>Performing configure step for 'lore_3rdpartylibs_qslog'
2>loading initial cache file
C:/kitt-lore-trunk/binary/lore/trunk/win64-vs2008/lore_3rdpartylibs_qslog/lore_3rdpartylibs_qslog-prefix/tmp/lore_3rdpartylibs_qslog-cache.cmake
2>-- Check for working C compiler using: Visual Studio 9 2008 Win64
2>-- Check for working C compiler using: Visual Studio 9 2008 Win64 -- works
2>-- Detecting C compiler ABI info
2>-- Detecting C compiler ABI info - done
2>-- Check for working CXX compiler using: Visual Studio 9 2008 Win64
2>-- Check for working CXX compiler using: Visual Studio 9 2008 Win64 -- works
2>-- Detecting CXX compiler ABI info
2>-- Detecting CXX compiler ABI info - done
2>-- Looking for Q_WS_X11
2>-- Looking for Q_WS_X11 - not found.
2>-- Looking for Q_WS_WIN
2>-- Looking for Q_WS_WIN - found


Sometimes, though, it does not work fine:


2>------ Build started: Project: lore_3rdpartylibs_qslog,
Configuration: Release x64 ------
2>Creating directories for 'lore_3rdpartylibs_qslog'
2>No download step for 'lore_3rdpartylibs_qslog'
2>No patch step for 'lore_3rdpartylibs_qslog'
2>No update step for 'lore_3rdpartylibs_qslog'
2>Performing configure step for 'lore_3rdpartylibs_qslog'
2>loading initial cache file
C:/kitt-lore-trunk/binary/lore/trunk/win64-vs2008/lore_3rdpartylibs_qslog/lore_3rdpartylibs_qslog-prefix/tmp/lore_3rdpartylibs_qslog-cache.cmake
2>-- Check for working C compiler using: Visual Studio 9 2008 Win64
2>Microsoft (R) C/C++ Optimizing Compiler Version 15.00.30729.01 for x64
2>Copyright (C) Microsoft Corporation.  All rights reserved.
2>cl /Od /D "WIN32" /D "_WINDOWS" /D "_DEBUG" /D
"CMAKE_INTDIR=\"Debug\"" /D "_MBCS" /FD /RTC1 /MDd
/Fo"cmTryCompileExec.dir\Debug\\"
/Fd"C:\kitt-lore-trunk\binary\lore\trunk\win64-vs2008\lore_3rdpartylibs_qslog\qslog\CMakeFiles\CMakeTmp\Debug/cmTryCompileExec.pdb"
/W3 /c /Zi /TC   /Zm1000
2>   ".\testCCompiler.c"
2>testCCompiler.c
2>-- Check for working C compiler using: Visual Studio 9 2008 Win64 -- works
2>-- Detecting C compiler ABI info
2>Microsoft (R) C/C++ Optimizing Compiler Version 15.00.30729.01 for x64
2>Copyright (C) Microsoft Corporation.  All rights reserved.
2>cl /Od /D "WIN32" /D "_WINDOWS" /D "_DEBUG" /D
"CMAKE_INTDIR=\"Debug\"" /D "_MBCS" /FD /RTC1 /MDd
/Fo"cmTryCompileExec.dir\Debug\\"
/Fd"C:\kitt-lore-trunk\binary\lore\trunk\win64-vs2008\lore_3rdpartylibs_qslog\qslog\CMakeFiles\CMakeTmp\Debug/cmTryCompileExec.pdb"
/W3 /c /Zi /TC   /Zm1000
2>   "..\..\..\..\..\..\..\..\..\Program Files (x86)\CMake
2.8\share\cmake-2.8\Modules\CMakeCCompilerABI.c"
2>CMakeCCompilerABI.c
2>-- Detecting C compiler ABI info - done
2>-- Check for working CXX compiler using: Visual Studio 9 2008 Win64
2>Microsoft (R) C/C++ Optimizing Compiler Version 15.00.30729.01 for x64
2>Copyright (C) Microsoft Corporation.  All rights reserved.
2>cl /Od /D "WIN32" /D "_WINDOWS" /D "_DEBUG" /D
"CMAKE_INTDIR=\"Debug\"" /D "_MBCS" /FD /EHsc /RTC1 /MDd
/Fo"cmTryCompileExec.dir\Debug\\"
/Fd"C:\kitt-lore-trunk\binary\lore\trunk\win64-vs2008\lore_3rdpartylibs_qslog\qslog\CMakeFiles\CMakeTmp\Debug/cmTryCompileExec.pdb"
/W3 /c /Zi /TP   /Zm1000
2>   ".\testCXXCompiler.cxx"
2>testCXXCompiler.cxx
2>-- Check for working CXX compiler using: Visual Studio 9 2008 Win64 -- works
2>-- Detecting CXX compiler ABI info
2>Microsoft (R) C/C++ Optimizing Compiler Version 15.00.30729.01 for x64
2>Copyright (C) Microsoft Corporation.  All rights reserved.
2>cl /Od /D "WIN32" /D "_WINDOWS" /D "_DEBUG" /D
"CMAKE_INTDIR=\"Debug\"" /D "_M.BCS" /FD /EHsc /RTC1 /MDd
/Fo"cmTryCompileExec.dir\Debug\\"
/Fd"C:\kitt-lore-trunk\binary\lore\trunk\win64-vs2008\lore_3rdpartylibs_qslog\qslog\CMakeFiles\CMakeTmp\Debug/cmTryCompileExec.pdb"
/W3 /c /Zi /TP   /Zm1000
2>   "..\..\..\..\..\..\..\..\..\Program Files (x86)\CMake
2.8\share\cmake-2.8\Modules\CMakeCXXCompilerABI.cpp"
2>CMakeCXXCompilerABI.cpp
2>-- Detecting CXX compiler ABI info - done
2>-- Looking for Q_WS_X11
2>Microsoft (R) C/C++ Optimizing Compiler Version 15.00.30729.01 for x64
2>Copyright (C) Microsoft Corporation.  All rights reserved.
2>cl /Od /I "C:\3rdpartylibs-lore\Qt\4.7.1\build\win64-vs2008\include"
/D "WIN32" /D "_WINDOWS" /D "_DEBUG" /D "CMAKE_INTDIR=\"Debug\"" /D
"_MBCS" /FD /RTC1 /MDd /Fo"cmTryCompileExec.dir\Debug\\"
/Fd"C:\kitt-lore-trunk\binary\lore\trunk\win64-vs2008\lore_3rdpartylibs_qslog\qslog\CMakeFiles\CMakeTmp\Debug/cmTryCompileExec.pdb"
/W3 /c /Zi /TC   /Zm1000
2>   ".\CheckSymbolExists.c"
2>CheckSymbolExists.c
2>.\CheckSymbolExists.c(8) : error C2065: 'Q_WS_X11' : undeclared identifier
2>-- Looking for Q_WS_X11 - not found.


The problem is these 'C2065 undeclared identifier' compiler errors.
They are generated while CMake tries to determine the capabilities of
the system. Most of the time, they are not included in the compiler
output (see successful case above). However when they do appear in the
compiler output, CMake flags them as "real" compiler errors, causing
the rest of the build to fail.

Can anyone think of a reason why the compiler would sometimes lose its
mind and spew extra output? Has anyone else observed this problem
while using ExternalProjects? Any ideas on workarounds? This is
driving me bonkers.

This is with CMake 2.8.5. Sorry I don't have a minimal repro case but
I can't even reliably reproduce this with the whole build system!

Other background information:

- The build machine where this happens most frequently has Bullseye
installed. Bullseye works by using some dark magic to replace calls to
Visual Studio's compiler tools (cl.exe, link.exe) with its own
versions that bake in extra information used for calculating code
coverage metrics. After some tweaking, I have verified that both the
main CMakeCache.txt (the one used by the overarching build system) and
the satellite CMakeCache (the one created and used by the
ExternalProject) are correctly pointing to the Visual Studio versions
of cl and link.

- This problem generally manifests as the first build of the day. Our
schedule of automated builds looks like this:

0. Remove entire build directory.

1. Nightly build checks out build scripts and source, creates binary
directory, runs build. (Everything in the project is built
out-of-source.)

2. Continuous build starts up. It removes the binary directory
(including all CMakeCaches) with ctest_empty_binary_directory() then
runs the build.

3. Continuous loop continues throughout the day, but the binary
directory is not emptied.

Even when the first Continuous build of the day fails with the problem
described above, subsequent builds are fine, presumably because CMake
has already done the system inspection so it doesn't need to build
cmTryCompileExec anymore.


Any insight would be appreciated!!

Thanks,
tyler