[cmake-developers] Review Request: Topic ExternalProject-independent-step-targets

Brad King brad.king at kitware.com
Mon Dec 9 10:06:10 EST 2013


On 12/09/2013 07:51 AM, Daniele E. Domenichelli wrote:
> And then adding an explicit dependency for each project that requires it
> 
>   add_dependency(${proj}-download SetupLocalXXXRepository)

...but again this requires the existing cases to be modified and
no longer tests that they work without this extra configuration.
By moving the new property test into a subdirectory or otherwise
making it not apply to the existing cases then that is not a problem.

However, the trouble you're having with Ninja still needs to be
solved because it could affect user projects (and a representative
case needs to be in the test too).

> AFAIK this should wait for SetupLocalXXXRepository to be finished
> before starting ${proj}-download

If both are logical CMake target names then that is the expected
behavior, yes.  The Makefile, VS, and Xcode generators all work
by grouping individual shell actions and their dependencies into
separate logical targets that have high-level ordering dependencies.

The Ninja generator (by design) tries to have monolithic dependencies
for all the low-level rules because it is more efficient at build time.
IIUC it tries to connect up all the low-level rule dependencies to
simulate the target-ordering dependencies that CMake defines.  Perhaps
that is not working here.  I'm not intimately familiar with it though.

Can you reproduce the dependency ordering failure with a few simple
add_custom_command and add_custom_target calls and no ExternalProject
module?  That will make it much easier to pin down, and the result
can be added to the general test suite (e.g. CustomCommand test) too.

Thanks,
-Brad



More information about the cmake-developers mailing list