[Cmake] Subdirectory dependencies

Brad King brad . king at kitware . com
Wed, 12 Dec 2001 10:51:40 -0500 (EST)

> Continuing the the dependency discussion, why is it necessary that
> "make -j 2" does things in the same order as "make"? From what I can
> see (with vxl), every executable and library target has full dependency
> information, and so any order followed by "make -j 2" should be valid.
Consider this situation:

Top level:

Directory A:
ADD_LIBRARY(AL al1.cxx al2.cxx al3.cxx)

Directory B:

Assume that everything has already been built once, so libAL.a exists. Now
consider a second build after a header included by al1.cxx has changed.
The cmake.depends file in B doesn't know the dependencies of al1, al2, and
al3.  A single threaded build will go into A, make sure AL is up-to-date,
and then go into B.  A multithreaded build with no dependency between A
and B will go into A and B at the same time.  B will see that libAL.a
exists, and link to it even if if isn't yet ready.  Then, A will finish,
libAL.a will be replaced, but B has already finished, so BE is out of
date, but make doesn't know, and nothing tells the user.

Authors of CMakeLists.txt files put the directories in the right order for
a single threaded build in the SUBDIRS command.  There is no reason that
this author should also have to specify any more information than that,
because building in that order guarantees that everything is up to date. A
multi-threaded build can simply go in the same order, and will never fail
due to missing dependencies.

I thought of similar arguments to yours when I first wrote the
SUBDIR_DEPENDS commands, having dismissed this simple approach.  After a
couple of months of fighting with "make -j 6" on a multiprocessor machine
despite SUBDIR_DEPENDS being in place, I decided that the simple approach
is better.  Since I made the change to automate it, I haven't had a single
problem with "make -j 6".

> I'm not convinced: "make -i" should be all that is necessary.
The way I look at it is that if you want to build a project with compiler
errors in it, then some special make option is needed.

> [ As an aside, and as I've posted before, I think CMake is in a
> position to locate a number of these automatic dependencies via
> LINK_DIRECTORIES, etc. This part of CMake is very much under
> utilitized. ]
We'll look at this when we have time.  Feel free to attempt an
implementation of this yourself. The main problem is that many projects
just put a LINK_DIRECTORIES command at the top level referring to several
of the common library locations.  Instead CMake will have to build a
dependency list from LINK_LIBRARIES and TARGET_LINK_LIBRARIES commands.  
However, it will have to reflect these dependencies by adding the
appropriate directory ordering.  Just depending on the library is not good
enough due to the above example.