[CMake] Parallel builds do not work correctly when using "cmake -E copy" to copy files

[Alan W. Irwin]

On 2007-12-14 10:32-0500 Brad King wrote:

> Alan W. Irwin wrote:
>> I am struggling with understanding the recursive make system that
>> CMake normally employs
>
> CMake employs a 2-level make recursion system that is independent of the
> directory structure.  The first level never builds anything...it just
> evaluates target-level dependencies with phony targets.  That determines
> the order in which targets must be built.  The second level is the
> build.make for each target.  This is where file-level dependencies are
> evaluated.
>
> In your example the file1...fileN rules are showing up in target1's
> build.make and target2's build.make but they should never be evaluated
> in the second target.  They are pulled in through the additional_file
> rule's dependencies on them (see below), but they should always be up to
> date if target2 doesn't build until after target1 finishes.  Then only
> the additional_file rule will be invoked.  However if there is no
> dependency from target2->target1 then both build.make files may be built
> simultaneously and you get race conditions causing the double evaluations.
>
> CMake traces through the dependencies of custom commands in each target.
> When it is constructing target2 it doesn't know that target1 will also
> provide rules for the files.  If you place the targets in different
> directories it would not be able to make this extra connection, but then
> the build would not work correctly unless you add the target-level
> dependency.  Any further explanation here will just duplicate my
> previous message so I'll stop.

That's fine.  Your combined explanation now makes sense and completely
confirms my working hypothesis that the make recursion system of CMake is
responsible for the parallel build issues I was encountering.  I hope I can
work around these PLplot parallel build issues (note the double copy issue
was only the most obvious one) by using extra target dependencies.  The
problem is that parallel build issues tend to appear and disappear depending
on load, the N level (for -j N), and hardware.  Thus, even if a whole flock
of PLplot developers confirm success for parallel builds, there could be
some subtle dependency issue left that we have missed, and some user down
the road is going to come up with a combination of load, N, and hardware
that triggers the parallel build problem because of that dependency issue.
As a PLplot developer, I don't like being in such an uncertain position!  I
wonder if really large projects such as KDE have attempted to deal with
parallel build issues for CMake or whether they have just given up on
parallel builds because the symptoms can be so intermittent and
non-reproducible.

I was well aware of the CMake file dependency limitation for separate
directories before, but I did not realize that limitation extends to file
dependencies in the _same_ directory when using parallel builds.  I
personally think these limitations of your 2-level make recursion system are
pretty ugly since they require CMake users to deploy nonintuitive (at least
from the make perspective) additional target-level dependencies as a
workaround for these issues. The problem is especially pernicious for the
parallel builds case since the symptoms are inherently difficult to
reproduce.

Obviously, CMake 2.4.x users are stuck with these file dependency issues and
their workarounds, but for obvious reasons and especially for the parallel
build case I hope the complete rework of the CMake dependency system that
has been mentioned previously on list will remove these limitations.

Is that complete rework actually going to happen for 2.6.x or is it currently
just a gleam in the CMake developer's eyes?

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state implementation
for stellar interiors (freeeos.sf.net); PLplot scientific plotting software
package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of
Linux Links project (loll.sf.net); and the Linux Brochure Project
(lbproject.sf.net).
__________________________

Linux-powered Science
__________________________