[CMake] ExternalProject sometimes fails due to cmTryCompileExec

Tyler tyler at cryptio.net
Wed Aug 31 01:34:57 EDT 2011 

Closing the loop on this in case someone else sees it someday. I have
a minimal repro case for this (see below) and a workaround.

The workaround comes from the "doctor, it hurts when I do this" school
of medicine. To prevent CMake from running the problematic
try_compiles, we just set the variables CMake is trying to calculate
by running the try_compiles:

    -DQ_WS_X11:INTERNAL=${Q_WS_X11}
    -DQ_WS_WIN:INTERNAL=${Q_WS_WIN}
    -DQ_WS_QWS:INTERNAL=${Q_WS_QWS}
    -DQ_WS_MAC:INTERNAL=${Q_WS_MAC}

With the minimal repro case below, I get the weird, verbose compiler
output every time. The build machine where this happens is an older XP
machine with a storied history, so my current best guess is that some
Visual Studio setting, old compiler, bad install, or quirk of the
environment is causing the extra output. If anyone knows of a switch
somewhere that could make Visual Studio noisier than it should be, I'd
love to hear about it.

Thanks,
tyler

###
### MINIMAL REPRO CASE
###

### CMakeLists.txt

cmake_minimum_required (VERSION 2.8)
project(test)

# Hardcode your own path to qmake or remove this and let FindQt4
discover it in your PATH or whatever.
set (QT_QMAKE_EXECUTABLE
"c:/3rdpartylibs-lore/Qt/4.7.1/build/win64-vs2008/bin/qmake.exe")

find_package(Qt4 REQUIRED)

set (cache_args
    -DQT_QMAKE_EXECUTABLE:PATH=${QT_QMAKE_EXECUTABLE}
    )

include(ExternalProject)
ExternalProject_Add(
    externalproject
    DOWNLOAD_COMMAND ""
    UPDATE_COMMAND ""
    SOURCE_DIR "${CMAKE_SOURCE_DIR}/externalproject"
    BINARY_DIR "${CMAKE_BINARY_DIR}/externalproject"
    CMAKE_CACHE_ARGS "${cache_args}"
    INSTALL_COMMAND ""
    )


### externalproject\CMakeLists.txt

cmake_minimum_required (VERSION 2.8)
project(external)

find_package(Qt4 REQUIRED)


On Thu, Aug 25, 2011 at 9:29 AM, Tyler <tyler at cryptio.net> wrote:
> 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
>

More information about the CMake mailing list