View Issue Details [ Jump to Notes ] [ Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0014820CMakeCMakepublic2014-03-20 19:092016-06-10 14:31
ReporterCarl Worth 
Assigned ToKitware Robot 
PrioritynormalSeverityfeatureReproducibilityalways
StatusclosedResolutionmoved 
PlatformLinuxOSDebianOS VersionDebian unstable
Product VersionCMake 2.8.12.1 
Target VersionFixed in Version 
Summary0014820: warn users about removing only CMakeCache.txt
DescriptionI am trying to build a project which uses cmake and that queries
CMAKE_EXECUTABLE_FORMAT. The project has been building inconsistently
for me, and I've tracked that down to CMAKE_EXECUTABLE_FORMAT returning
an incorrect result after I remove the CMakeCache.txt file. (Before
removing the cache, it returns a correct value of 'ELF'. After removing
the cache, it returns an incorrect value of ''.)
Steps To ReproduceHere is a session showing the bug.

First, the contents of the files:

$ ls
CMakeLists.txt
$ cat CMakeLists.txt
cmake_minimum_required (VERSION 2.8)

include (CMakeDetermineCompilerId)
if (CMAKE_EXECUTABLE_FORMAT STREQUAL "ELF")
   message ("Correct. CMAKE_EXECUTABLE_FORMAT is '${CMAKE_EXECUTABLE_FORMAT}'")
else ()
   message ("Incorrect. CMAKE_EXECUTABLE_FORMAT is '${CMAKE_EXECUTABLE_FORMAT}'")
endif ()

Then, correct results:

$ cmake .
-- The C compiler identification is GNU 4.8.2
-- The CXX compiler identification is GNU 4.8.2
-- Check for working C compiler: /home/cworth/bin/cc
-- Check for working C compiler: /home/cworth/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working CXX compiler: /home/cworth/bin/g++
-- Check for working CXX compiler: /home/cworth/bin/g++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
Correct. CMAKE_EXECUTABLE_FORMAT is 'ELF'
-- Configuring done
-- Generating done
-- Build files have been written to: /home/cworth/src/cmake_bug
$ rm CMakeCache.txt
$ cmake .
Correct. CMAKE_EXECUTABLE_FORMAT is 'ELF'
-- Configuring done
-- Generating done
-- Build files have been written to: /home/cworth/src/cmake_bug

Now, after remove CMakeCache.txt, the incorrect results:

$ rm CMakeCache.txt
$ cmake .
Incorrect. CMAKE_EXECUTABLE_FORMAT is ''
-- Configuring done
-- Generating done
-- Build files have been written to: /home/cworth/src/cmake_bug

Finally, I can get to correct results again by removing the CMakeFiles
directory:

$ rm -r CMakeFiles/
$ cmake .
-- The C compiler identification is GNU 4.8.2
-- The CXX compiler identification is GNU 4.8.2
-- Check for working C compiler: /home/cworth/bin/cc
-- Check for working C compiler: /home/cworth/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working CXX compiler: /home/cworth/bin/g++
-- Check for working CXX compiler: /home/cworth/bin/g++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
Correct. CMAKE_EXECUTABLE_FORMAT is 'ELF'
-- Configuring done
-- Generating done
-- Build files have been written to: /home/cworth/src/cmake_bug

I'm assuming that it is a valid thing to remove CmakeCache.txt and
expect things to still work. After all, cmake itself tells me to do
that in some cases:

$ cmake . -GNinja
CMake Error: Error: generator : Ninja
Does not match the generator used previously: Unix Makefiles
Either remove the CMakeCache.txt file or choose a different binary directory.
Additional InformationThanks in advance for any information, (particularly if I am doing anything wrong).

-Carl
TagsNo tags attached.
Attached Files

 Relationships

  Notes
(0035457)
Nils Gladitz (developer)
2014-03-21 04:55

 I tripped over a similar issue before.
Some information (cmake version specific information) is cached in the CMakeFiles directory rather than CMakeCache.txt.

In my case it seemed to be due to CMakeFindBinUtils.cmake not rerunning.
In this case probably CMakeDetermineCompilerId.cmake.
(0035460)
Brad King (manager)
2014-03-21 08:30

 You need to remove CMakeFiles when removing CMakeCache.txt. I've updated the reported message accordingly:

 cmake: Advise user to remove CMakeFiles with CMakeCache.txt
 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=bccc056b [^]

Normally the expectation is that an out-of-source build tree is wiped out completely and re-created from scratch.
(0035467)
Carl Worth (reporter)
2014-03-21 12:13

 Thanks for updating the message.

Still, it seems an odd expectation that the only way to rebuild is to wipe
everything out again. Isn't the whole point of these dependency-tracking
build systems like make and ninja to allow for incremental rebuilds?

How hard would it be to fix the system to do the right thing in this case?

That could perhaps even be something as crude as noticing that there's no
CMakeCache.txt file and in that case removing (or just ignoring) the content
of CMakeFiles?

-Carl
(0035468)
Brad King (manager)
2014-03-21 12:19

 Re 0014820:0035467: If there is no CMakeCache.txt in a directory then we don't know for sure it was the top of a build tree and might wipe files out that we should not. Incremental build systems do not survive "rm Makefile", and "rm CMakeCache.txt" is much like that for CMake.
(0035469)
Carl Worth (reporter)
2014-03-21 12:30

 > If there is no CMakeCache.txt in a directory then we don't know for
> sure it was the top of a build tree and might wipe files out that we
> should not. Incremental build systems do not survive "rm Makefile",
> and "rm CMakeCache.txt" is much like that for CMake.

Fair enough.

But legitimate operations (like wanting to switch from one build
generator to another) are currently directing the user toward doing
this non-survivable removal. And as seen in this bug report, the
actual steps toward doing a removal that the build system will survive
is more complicated than just "rm CMakeCache.txt".

So I think cmake should really aquire the ability to do all of the
cleanup necessary here if someone wants to start over.

Maybe something like "cmake -f" or "cmake --flush-cache" for cmake to
flush the cache? That would be less fragile and certainly easier for
the user to carry out correctly than "remove the CmakeCache.txt file
and CMakeFiles".

-Carl
(0035470)
Nils Gladitz (developer)
2014-03-21 12:47

 If switching generators is your use case wouldn't it make more sense to wipe the entire build directory?

The different generators may produce different intermediary, temporary and final outputs which would be left over when switching as well.

Perhaps you are not using out of source tree builds (yet)?
(0035471)
Carl Worth (reporter)
2014-03-21 13:13

 > If switching generators is your use case wouldn't it make more sense
> to wipe the entire build directory?If switching generators is your
> use case wouldn't it make more sense to wipe the entire build
> directory?

Well, I only know that it was switching generators that originally
caused this problem after a lot of fairly-painful trial-and-error to
isolate the problem.

From a top-level user perspective, I was just getting mystic build
failures. Sometimes everything built fine, and sometimes things failed
to link. I'd ask around to people who are more expert than me in
cmake, and invariably the answer I got was:

    "You must have something bad cached. Try removing CMakeCache.txt"

That definitely seems to be the common wisdom for fixing build
problems. It's certainly not common wisdom that removing this file
actually *introduces* build problems, (see my original report
above). Also note that the original bug report is caused simply by
removing CMakeCache.txt and does not involve switching build
generators at all.

So the current facts as I see them are:

  1. There's a cultural perception that "rm CMakeCache.txt" is a
     legitimate and useful operation.

  2. In fact, "rm CMakeCache.txt" can currently break builds, (causing
     various cmake tests to return incorrect values).

The combination of those two facts leads to hard-to-diagnose problems,
giving the perception that cmake is fragile.

I don't think there's much that the cmake project can do to change #1
above. We've found one case where the cmake code itself advertises "rm
CMakeCache.txt" and have updated it, but I think this perception is
ingrained enough that it's not worth fighting.

So I think attention should really be given to fix 0000002. That is, making
it legitimate for the user to delete CMakeCache.txt to flush the
cache. This will require identifying and fixing cases where tests
(such as CMAKE_EXECUTABLE_FORMAT) are currently returning incorrect
values after CMakeCache.text is removed.

-Carl
(0035524)
Brad King (manager)
2014-03-26 09:10

 Re 0014820:0035471: Removing parts of a build tree but not all of it is asking for trouble, IMO. I think the path forward here is to address item (1) directly by introducing a warning when a CMakeFiles directory is present without CMakeCache.txt.

One possible place to do that is in cmake::LoadCache but the interactive dialogs may re-create CMakeCache.txt before that method runs. Therefore cmake, ccmake, and cmake-gui would each need to be taught to check for this case and warn at the appropriate time.
(0042512)
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
2014-03-20 19:09 Carl Worth New Issue
2014-03-21 04:55 Nils Gladitz Note Added: 0035457
2014-03-21 08:30 Brad King Note Added: 0035460
2014-03-21 12:13 Carl Worth Note Added: 0035467
2014-03-21 12:19 Brad King Note Added: 0035468
2014-03-21 12:30 Carl Worth Note Added: 0035469
2014-03-21 12:47 Nils Gladitz Note Added: 0035470
2014-03-21 13:13 Carl Worth Note Added: 0035471
2014-03-26 09:10 Brad King Note Added: 0035524
2014-03-26 09:10 Brad King Severity minor => feature
2014-03-26 09:10 Brad King Status new => backlog
2014-03-26 09:10 Brad King Summary CMAKE_EXECUTABLE_FORMAT behaves incorrectly after removing CMakeCache.txt => warn users about removing only CMakeCache.txt
2016-06-10 14:29 Kitware Robot Note Added: 0042512
2016-06-10 14:29 Kitware Robot Status backlog => 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