[Cmake] Dependency handling problems with 1.8

[Amitha Perera]

On Thu 02 Oct 2003, Ken Martin wrote:
> Hi Amitha,
> 
> Good idea Amitha. I think this issue can be solved. We also came up with
> something yesterday and I'm not sure which is the better idea. The makefiles
> already have code to jump across and build targets that a target depends on.
> Currently this is only done if the target doesn't exist. There is no reason
> I know of that we couldn't perform that jump more frequently.

> Specifically, in cases where we know the build order doesn't match
> the dependency order (which is what that warning message indicates)
> then always jump to the dependency target and build it (just do a
> make to make sure it is up to date).

This is essentially the solution that VC 7 uses. It leads to a much
longer build time, because it takes time to do a "make all" on
potentials 10s of directories, unnecessarily.

> It will cause more make invocations but either solution will cause
> that.

Not really. What I suggested would not cause more invocations; it'll
just do them in a different (correct) order.

> the approach I just outlined provides better support for people building in
> a subdirectory (which some insist should work even if they have never done a
> make from the top).

If the dependency graph is appropriately linearized, then all kinds of
options are available. I would suggest that the different ways are
acomplished by different make targets. For example:

make all
    Generates the subtree in the correct order; fails if
    something outside the subtree is incorrect (not built, out of
    date). This is the default behaviour expected on Unix systems.

make with-depends
    Same as "make all", but will jump outside the subtree to check on
    dependencies. This is essentially the approach you suggested.

make local
    Similar to "make all", but will not process subdirectories

make local-with-depends
    Rebuild the targets in the current directory, and rebuild their
    dependencies.

make ABC
    Rebuild a specific target (libABC, ABC.lib, ABC.exe, or whatever
    is appropriate)

make ABC-with-depends
    Rebuild a target and its dependencies.

Note that the latter targets are probably necessary to implement some
of the former, and hence it doesn't hurt to expose the additional
functionality.

Also, I think that these targets should *not* jump out of the current
CMake build tree to a different project tree.

> I think both approaches fail to support circular dependencies (which
> for some reason some people insist on using).

Yes. I don't think there is any real way of supporting circular
dependencies in a cross-platform way. For example, can Windows DLLs
even support circular dependencies? However, linearizing the
dependency graph, breaking cycles, and inserting an extra target to
account for the circularity, will get as close as can be expected, IMO.

Amitha.