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

[Alan W. Irwin]

On 2007-12-13 15:39-0500 Bill Hoffman wrote:

> Alan W. Irwin wrote:
>
>> My obvious next step is to try and make a simple CMake example that 
>> reliably
>> reproduces the bug, but this is such an important bug (at least for those
>> with access to multiprocessors who want to use parallel builds) that I
>> thought the above result was worth reporting immediately since it tends to
>> point the finger at something CMake is doing rather than some bug in GNU
>> make.
>> 
>
> We use -j N builds all the time at Kitware for VTK, ParaView and CMake.  It 
> is however, possible to create input to CMake that will not work in a 
> parallel environment.   A simple example would be the best way to figure out 
> if there is a way around the issue you are having.  One thing you might want 
> to look at is the add_dependancy command, and make sure that your custom 
> targets are built in some order.  From your email, I am not exactly sure what 
> targets are involved and what files are created at what time.

It was good to hear that make -j N normally works with CMake.

To answer your question, from the CMake language fragment in the first
e-mail on this issue, there is a custom command (with OUTPUT signature with
full pathname) for each file to be copied, and then an overall "ALL" custom
target that file depends (with full pathname) on those OUTPUT files.

So just keeping narrowly focussed on that fragment there is only one "ALL"
custom target and ADD_DEPENDENCIES would not help since it only works on
targets.  Thus, I doubt there is anything locally wrong with dependencies
there.  It is possible some other dependency is making a dependency pattern
that triggers the bug, but I should know more about that when I have a
simpler example that triggers the bug (or not).

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
__________________________