[CMake] FYI - From Ninja-build mailing list - Fwd: Proposal: restat rules

[Peter Collingbourne]

On Thu, Sep 15, 2011 at 03:28:42PM +0200, Andreas Mohr wrote:
> Hi,
> 
> On Wed, Sep 14, 2011 at 12:00:05PM -0400, cmake-request at cmake.org wrote:
> > Date: Wed, 14 Sep 2011 05:37:20 -0400
> > From: Clifford Yapp <cliffyapp at gmail.com>
> > 
> > Looks like that's working.  Running ninja again, I'm seeing another issue:
> > 
> > BRL-CAD uses dependency assignment to make sure our build time delta
> > calculator is the last target to be built (and hence actually times the
> > build).  With ninja, it doesn't seem to be respecting this, but instead
> > tries to run the delta target immediately.  Do custom targets respect
> > dependency information?

Yes, but the dependencies are currently only attached to the target,
not to any of its custom commands.  This behaviour is correct for
CMake's built-in targets, such as 'install' and 'test', for which the
commands are attached directly to the target, but add_custom_target
is actually implemented internally using custom commands (the command
given to add_custom_target is stored as a custom command attached to
a dummy source file), so the target dependencies are not currently
attached in the correct place for add_custom_target.

> IOW, from what I'm gathering here, it seems as if   scm_sos_pull_db_tree   lists   its _internal_
> target/rule/whatever CMakeFiles/scm_sos_pull_db_tree with same-hierarchy priority as scm_sos_setup.
> And that internal target/rule/whatever then gets executed in advance, despite scm_sos_setup not having been executed (prepared) yet.

This is a symptom of the behaviour described above.

> IOW, it's a MISTAKE to implement (emulate) add_custom_command() via inner targets in Ninja build config,
> since those inner targets don't inherit those dependency constraints ("ordering")
> which have been explicitly imposed on their outer targets.
> 
> So:
> - either keep custom commands implemented via inner targets - and then make sure
>   that those inner (internal!) targets do have _all_ dependencies of the outer,
>   CMake-public target specified
> - or don't implement custom commands via internal, logically disconnected targets  [better?]

The former is the correct solution.  The Ninja generator already
does this for object files to ensure that target dependencies are
built before any object file in the target (one of the build systems
I tested with uses a target dependency to generate a header file used
by some of the target's source files).  I now realise this also needs
to happen for custom commands.

Thanks,
-- 
Peter