[cmake-developers] Ninja delayed dependency stat (was: cmNinjaTargetGenerator: Create files to satisfy pending-creation imported libs)

[Brad King]

On 06/06/2014 12:33 PM, Sam Spilsbury wrote:
> I'm not particularly keen on this implementation, but it was the best
> thing I can think of for now. The trade off is that marking a target
> as IMPORTED doesn't necessarily mean the user is generating it and we
> end up calling the linker against a plain-text file, which results in
> a rather cryptic error message.

The file this touches may very well be newer than all the real dependencies
of the rule to build it in the external build system so it may never get
replaced with the real file.

> The problem here is that Ninja does all its dependency scanning before
> building any targets, unlike other generators which do it once the
> target is reached. Thus if an IMPORTED library is being created as
> part of using ExternalProject_Add, then the Ninja generator will get
> upset and refuse to run.
[snip]
> Broader context: This prevents me from using ExternalProject_Add with
> the Ninja generator generally.

This has come up several times.  Here are some more links that
may be related for reference:

 http://www.cmake.org/Bug/view.php?id=13538
 http://www.cmake.org/Bug/view.php?id=13574
 http://www.cmake.org/Bug/view.php?id=14747
 http://www.cmake.org/Bug/view.php?id=14771
 https://github.com/Kitware/CMake/pull/68

The problem is that we want to be able to have a build rule
that says "bring that other rule up to date first, then stat
my dependencies".  AFAICT ninja has no way to express this.

An issue has been reported upstream here:

 https://github.com/martine/ninja/issues/760

The fundamental problem is Ninja's stat-then-build design.
They do have "restat" to declare that the output files should be
re-checked after a rule is run.  We need a way to say that a
rule's input dependencies should be restat-ed after its
order-only dependencies are satisfied and up to date.

-Brad