On Thu, Sep 15, 2011 at 03:28:42PM +0200, Andreas Mohr wrote:
> Hi,
>
> On Wed, Sep 14, 2011 at 12:00:05PM -0400, [email protected] wrote:
> > Date: Wed, 14 Sep 2011 05:37:20 -0400
> > From: Clifford Yapp <[email protected]>
> >
> > 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
_______________________________________________
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
