View Issue Details [ Jump to Notes ] [ Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0015893CMakeCMakepublic2015-12-22 20:002016-06-10 14:31
ReporterPaul Smith 
Assigned ToKitware Robot 
PrioritynormalSeveritymajorReproducibilityalways
StatusclosedResolutionmoved 
PlatformIntelOSGNU/LinuxOS VersionUbuntu 15.10
Product VersionCMake 3.4.1 
Target VersionFixed in Version 
Summary0015893: If cmake needs to restart due to changed compiler, it loses all command line variable assignments
DescriptionIf I invoke "cmake -DFOO=bar ." and cmake discovers that the compiler is changed and needs to re-invoke itself it does so automatically but in the process it loses all the -D options from the command line, so they're not set in the restart making it inaccurate.
Steps To ReproduceGiven this CMakeLists.txt:

cmake_minimum_required(VERSION 3.4.1)
project(Restart NONE)
set(BUILDNUM "0" CACHE STRING "Build Number")
if(EXISTS "my/gcc")
    set(CMAKE_C_COMPILER "${CMAKE_CURRENT_BINARY_DIR}/my/gcc"
        CACHE FILEPATH "C compiler" FORCE)
else()
    set(CMAKE_C_COMPILER "/usr/bin/gcc"
        CACHE FILEPATH "C compiler" FORCE)
endif()
message(STATUS "Build Number: ${BUILDNUM}")
enable_language(C)

Now run it once without the local "my" link, overridding BUILDNUM:

$ cmake -DBUILDNUM=99 .
-- Build Number: 99
-- The C compiler identification is GNU 5.2.1
-- Check for working C compiler: /usr/bin/gcc
-- Check for working C compiler: /usr/bin/gcc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Configuring done
-- Generating done
-- Build files have been written to: /home/psmith/src/cmake/restart

Now create the symlink and run it again: it will change the compiler and restart:

$ ln -s /usr/bin my
$ cmake -DBUILDNUM=99 .
-- Build Number: 99
-- Configuring done
You have changed variables that require your cache to be deleted.
Configure will be re-run and you may have to reset some variables.
The following variables have changed:
CMAKE_C_COMPILER= /home/psmith/src/cmake/restart/my/gcc

-- Build Number: 0
-- The C compiler identification is GNU 5.2.1
-- Check for working C compiler: /home/psmith/src/cmake/restart/my/gcc
-- Check for working C compiler: /home/psmith/src/cmake/restart/my/gcc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Configuring done
-- Generating done
-- Build files have been written to: /home/psmith/src/cmake/restart

Note how initially the value of BUILDNUM is 99, but then cmake decides to re-execute itself and afterwards that override is lost and we get the default value of "0".
TagsNo tags attached.
Attached Files

 Relationships

  Notes
(0040905)
Antonio (reporter)
2016-04-21 10:21

 The compiler should never change after the generation. In case, you have to regenerate from scratch.
(0040916)
Paul Smith (reporter)
2016-04-21 14:26

 I'm not sure I understand your point. If you examine the example I provided, you'll see that cmake detects, by itself, that the compiler has changed from the previous run and it clears the configuration and restarts itself automatically. It then constructs a new configuration and exits with a success error code.

So, there's no way to know (by checking the exit code) that anything weird happened: it seems like a completely normal run... but the values of the command line variables have been lost.

Either cmake should fail immediately when a compiler change happens so that it's clear that the user needs to take action such as clearing the configuration and restarting, or else (better IMO) it should automatically recreate the configuration as it does now, but correctly preserve the command line settings during the recreation.
(0040917)
Brad King (manager)
2016-04-21 14:34

 FWIW, CMake's delete-cache-on-compiler-change feature was created specifically for the use case of selecting CMAKE_C_COMPILER/CMAKE_CXX_COMPILER inside the ccmake dialog interactively when first creating a tree. It has not been well-tested for other use cases, and is not really supported for anything else.

Project code should not try to set/force the compiler itself. It should be up to the user invoking CMake to choose a compiler.
(0042904)
Kitware Robot (administrator)
2016-06-10 14:29

 Resolving issue as `moved`.

This issue tracker is no longer used. Further discussion of this issue may take place in the current CMake Issues page linked in the banner at the top of this page.

 Issue History
Date Modified Username Field Change
2015-12-22 20:00 Paul Smith New Issue
2016-04-21 10:21 Antonio Note Added: 0040905
2016-04-21 14:26 Paul Smith Note Added: 0040916
2016-04-21 14:34 Brad King Note Added: 0040917
2016-06-10 14:29 Kitware Robot Note Added: 0042904
2016-06-10 14:29 Kitware Robot Status new => resolved
2016-06-10 14:29 Kitware Robot Resolution open => moved
2016-06-10 14:29 Kitware Robot Assigned To => Kitware Robot
2016-06-10 14:31 Kitware Robot Status resolved => closed

Copyright © 2000 - 2018 MantisBT Team