View Issue Details Jump to Notes ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0013123CMakeCTestpublic2012-04-12 04:392013-11-04 08:10
ReporterNils Gladitz 
Assigned ToNils Gladitz 
PrioritynormalSeveritymajorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product VersionCMake 2.8.7 
Target VersionFixed in VersionCMake 3.0 
Summary0013123: ctest_empty_binary_directory failure is too silent
DescriptionIn my last night's CDash scheduled build on a windows client there were suspiciously few compiler warnings showing up. Apparently the ctest_empty_binary_directory failed somehow and I got an incremental instead of a clean rebuild.

I found two subdirectories with xml submission files from two different dates under the Testing directory.

I'd prefer the whole build to fail in case ctest_empty_binary_directory fails (or at least some very visible failure notification on CDash).
TagsNo tags attached.
Attached Files

 Relationships

  Notes
(0029137)
David Cole (manager)
2012-04-12 09:24
edited on: 2012-04-12 09:26

As a work-around, until such time as anybody has time to spend on doing something to address this issue...

You could check for existence of the directory yourself immediately after ctest_empty_binary_directory, and message(FATAL_ERROR if it's still there.

Something like:
  ctest_empty_binary_directory(${CTEST_BINARY_DIRECTORY})
  if(EXISTS "${CTEST_BINARY_DIRECTORY}")
    message(FATAL_ERROR "error: dir still exists after ctest_empty_binary_directory")
  endif()

(Or does that not work, because the dir does still exist, but it's empty...? If that's the case, you could still do a file(GLOB and count the results. If they're non-zero, then it's the FATAL_ERROR...)

We will not fix this by causing a fatal error internally when ctest_empty_binary_directory fails because we intentionally try to avoid failing fatally from any ctest -S script for any reason.

We think that there are so many different use cases where people want the failures to occur and then be communicated to the CDash server by a subsequent ctest_submit call, that we simply make it a rule to never let errors be fatal in this context (as far as we can help it)...

It is quite reasonable for us to add some "try again" on delete failure code, or a return value from ctest_empty_binary_directory so that you could handle it in your script (of course, the "if EXISTS" test should work pretty well already) -- but we won't make this into an error that stops the script. If that's what you want, it's up to your script to do it anyway.

(0029138)
Nils Gladitz (developer)
2012-04-12 10:06

Yes, I'd certainly want some sort of error submission to CDash.
Is that currently possible? Can I conditionally notify CDash of a script failure which is neither part of Update, Configure, Build nor Test?

I guess I could make all subsequent steps - except for the submission - conditionally depend on success of ctest_empty_binary_directory so I'd at least get a broken looking entry on CDash indicating something (though without indicating what specifically) went wrong.

There seems to be a subsequent problem that if ctest_empty_binary_directory fails somewhere in the middle it might still have removed CMakeCache.txt.

So any later run will fail at ctest_empty_binary_directory because it refuses to remove a directory without CMakeCache.txt.

A possible fix might be having ctest_empty_binary_directory delete CMakeCache.txt last.

if(EXISTS "${CTEST_BINARY_DIRECTORY}") itself seems to work indicating that ctest_empty_binary_directory does delete the directory itself even though the name may imply otherwise.
(0030400)
David Cole (manager)
2012-08-11 21:35

Sending old, never assigned issues to the backlog.

(The age of the bug, plus the fact that it's never been assigned to anyone means that nobody is actively working on it...)

If an issue you care about is sent to the backlog when you feel it should have been addressed in a different manner, please bring it up on the CMake mailing list for discussion. Sign up for the mailing list here, if you're not already on it: http://www.cmake.org/mailman/listinfo/cmake [^]

It's easy to re-activate a bug here if you can find a CMake developer who has the bandwidth to take it on, and ferry a fix through to our 'next' branch for dashboard testing.
(0034343)
Nils Gladitz (developer)
2013-11-04 08:10

Fixed by http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=ae57fb8ef6bd047f5c11851dfbebe7a0b7960fc4;hp=f3698f7c4a19470eb2152ce5acfbce564cc6d4f5 [^]

 Issue History
Date Modified Username Field Change
2012-04-12 04:39 Nils Gladitz New Issue
2012-04-12 09:24 David Cole Note Added: 0029137
2012-04-12 09:26 David Cole Note Edited: 0029137
2012-04-12 10:06 Nils Gladitz Note Added: 0029138
2012-08-11 21:35 David Cole Status new => backlog
2012-08-11 21:35 David Cole Note Added: 0030400
2013-11-04 08:10 Nils Gladitz Note Added: 0034343
2013-11-04 08:10 Nils Gladitz Status backlog => resolved
2013-11-04 08:10 Nils Gladitz Fixed in Version => CMake 3.0
2013-11-04 08:10 Nils Gladitz Resolution open => fixed
2013-11-04 08:10 Nils Gladitz Assigned To => Nils Gladitz
2013-11-04 08:10 Nils Gladitz Status resolved => closed


Copyright © 2000 - 2018 MantisBT Team