[CMake] CMake loses/switches generator, breaking build directories

[Jens Weggemann]

Hello,

I've run into a problem where rerunning CMake (for instance, automatically
from Visual Studio via the ZERO_CHECK target) would sometimes switch to a
different generator, like from 64-bit to 32-bit, completely messing up the
build directory.

The reason is that CMake can drop information about the previously chosen
generator. In such cases, when CMake is called again, it will try to detect
the generator anew, and there is no guarantee that will choose the previous
generator.
It's easily reproduced:

A dummy CMakeLists.txt:

    cmake_minimum_required(VERSION 3.3)
    project(problem)
    # message(FATAL_ERROR ouch)
    # undefined_function()
    # find_package(missing_package REQUIRED)

A call to
> cmake -G "Visual Studio 12 2013 Win64"

will store this entry in CMakeCache.txt:
CMAKE_GENERATOR:INTERNAL=Visual Studio 12 2013 Win64

So far, so good. Now uncomment any of the three commented lines in
CMakeLists.txt and either run cmake again without explicitly specifying the
generator or build the VS solution (which effectively does the same). The
cmake run will fail and the CMakeCache.txt is re-written, but it will now
lack the CMAKE_GENERATOR entry.

Now the build directory is doomed unless one explicitly specifies the Win64
generator again. To see why, fix the CMakeLists.txt by commenting out the
bad line.
CMake will detect the generator anew and (depending on platform and
installed IDEs, of course) might come up with "Visual Studio 12 2013". Note
that detection will never use the Win64 version of that generator, so it
will always guess wrong in this case. Furthermore, because there was no
generator entry previously, CMake will not fail because of non-matching
generators and happily create a mess of broken projects in the build
directory.

I couldn't so far find a reasonable workaround. Why does CMake rewrite the
CMakeCache in the case of a fatal error anyway? Can't it at least preserve
the previous value of CMAKE_GENERATOR?

Thanks,
Jens
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20151001/f5c5fa18/attachment-0001.html>