[CMake] Trouble with parallel builds for targets created by add_executable, target_link_libraries, and add_library

[Alan W. Irwin]

On 2009-09-29 19:46-0400 Bill Hoffman wrote:

> Alan W. Irwin wrote:
>> On 2009-09-29 16:36-0400 Bill Hoffman wrote:
>> 
>>> make -j N is only supported with the all target.
>> 
>> How difficult would it be to implement parallel build support for more than
>> just the "all" target? Note, if there is some limitation that makes it
>> impractical or inefficient to implement this current "all" target 
>> capability
>> for every target, you could instead implement this capability just for the
>> targets where this capability is wanted (as designated, say, by a
>> PARALLEL_BUILD=ON target property).
>> 
> It is very hard to implement on top of make.  Let me restate what I mean, it 
> is not the all target that is special.  You can do make -j N target.  You 
> just can't do make -jN target1 target2 if target1 and target2 have a common 
> target that they depend on.

Hi Bill:

I agree that is not too bad a limitation (compared to what you first
stated). When using my new test framework, I have tended to use one custom
target which depended on a whole group of other custom test targets.  That
scenario satisfies your criterion of running parallel builds with only one
target at a time, and indeed I didn't notice any parallel build issues for
that case.  So if I am able to anticipate the usual combinations of tests
our developers will want to run, and create a custom target for each such
combination, we should be okay.

> The /fast targets could be used to avoid the issue you are having 
> maybe...
>
> make -j2 x01c/fast x02c
>
> Then it will only trace the depends of one of them...  I have not tested that 
> but it might work... :)

Just as a matter of interest that make command didn't work (because the
required plplotd dependency of x01c was missing) but

make -j2 x01c x02c/fast

worked without any attempts to double build plplotd.  But I think that 
worked only because x01c and x02c have absolutely common dependencies and
/fast won't work for our more usual case where the tests have combinations
of unique dependencies as well as some dependencies that are common with
other tests.  But as I said above, I think we are okay, now that we know the
exact limitation on parallel builds.

Thanks for clarifying that limitation.

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
__________________________