Automatic call of cleandead ninja tool

Hello,

we have some problems with the automatic call of the “cleandead” tool of ninja. If a target file to be removed is read-only (which might be required), ninja failed to delete the file. This results that the cmake-call itself failed, although a valid ninja build file could be created, and the resulting build would also be ok.

While it makes sense that this call is done after the ninja build file is created (it must be performed after the cmake-call and before the ninja-call), it should not result in an breaking error.

Here are my suggestions to fix the problem:

  1. ninja forces the remove (tries to get write permissions and then removes the file)
  2. the ninja errors becomes a warning (so the failure is not breaking the cmake call)
  3. CMake gets an option to skip the call. (One might think about a ctest_cleandead() command in this case).

How to reproduce (simplest case, note that there may be many ways the file gets read-only state):
Create a target, which just copies a read-only file from source-tree into build-tree.
run cmake
remove (comment out) the target
run cmake again

Greetings
Thomas

Thomas Rhiem
Software Development
MAGMA Gießereitechnologie GmbH
T: +49 241 88901 236
W: www.magmasoft.de
E: T.Rhiem@magmasoft.de
GERMANY ● USA ● BRAZIL ● SINGAPORE ● SOUTH KOREA ● CHINA ● INDIA ● TURKEY ● CZECH REPUBLIC

Please note that our shipping and billing address and contact details including phone number have changed. Please update your records to replace our previous address: Kackertstraße 11, DE-52072 Aachen, with the following new address: MAGMA Gießereitechnologie GmbH, Kackertstraße 16-18, DE-52072 Aachen

MAGMA Gießereitechnologie GmbH | Kackertstraße 16-18, 52072 Aachen, Germany | Legal form: GmbH, Register court: Aachen HRB 3912, Value added tax identification number: DE121745780 | Management: Dr. Marc C. Schneider (CEO and President), Dr.-Ing. Jörg C. Sturm (Managing Director)

If you have a read-only output file, how would it have worked in a normal build? Does the tool that writes it upgrade permissions first? Or does it write elsewhere and then rename replace it?

I think the best thing to do here would be to have ninja to error on failure to remove a file. Since it is cleandead, the file doesn’t actually matter and removal is just a courtesy.

@brad.king Thoughts?

Some tools write into the same directory where they read the input from. For such tools the normal way is to copy the sources into the build-directory (if changed) and then call the tool inside the build directory. Using a SCM with explicit checkouts (e.g. perforce or ClearCase) the source files are read-only until explicit checked out. So the copy also is read-only, if nothing special is done.
Unpacking an archiv might also result in read-only files.

Hmm. I’d take the issue up to the ninja developers to have it ignore failures to remove old files (which shouldn’t hurt anything if they’re just laying around). https://github.com/ninja-build/ninja