[Scons-users] Prioritization of builds

Evan Driscoll driscoll at cs.wisc.edu
Fri Jan 15 20:51:16 EST 2016


I have a similar situation to Brian Cody, where if the wrong source 
files get updated, I can wind up with a 30-minute build that does 
*almost everything* in the first 15 minutes but that spends another 15 
minutes serially running a ton of targets. I've /also/ wished that I 
could say "prioritize these targets" so it would build the 
must-be-done-serially targets ASAP and then build everything else around it.

The 'scons <those targets>; scons' script idea wouldn't really help in 
my case; the benefit would be from the fact that much of the first 15 
minutes /could/ be done in parallel with everything from the second 15 
minutes.

The "priority" thing feels pretty natural to me and not anti-SCons... 
you're still not anywhere close to saying "you build this by taking 
these steps." You're still specifying the DAG, you're still letting 
dependency resolution do it's thing, you're just saying "build these 
targets first." I guess something that automatically recorded the time 
and then tried to pick the best scheduling would be a bit clearer, but I 
don't think it's necessary to keep the flavor.


On a somewhat but not entirely unrelated note, the other thing that 
would be sometimes helpful to me is a *memory* aware version of -j. On 
many of our machines, we are memory constrained rather than CPU 
constrained. So the question then comes up with what do you pass as -j? 
If you pass a high number, you start thrashing when it hits the larger 
files; if you pass a small number, there's a lot of lost parallelism 
during much of the build. ('scons <not-memory-constrained targets> -j8; 
scons -j4' /does/ work very well for this problem.)

I've actually thought about and at one point started writing a wrapper 
for gcc that just passes through to real gcc but doesn't invoke the 
compiler until the memory use is below a threshold, but never got around 
to getting everything to work with it. (I don't remember what the 
problem was.) Also thought about making the wrapper silently kill and 
re-invoke the compiler if the memory use started getting too high.

This is another place where, if SCons recorded memory use of the build 
steps, it could use that information to predict a better build order. 
Though I recognize that would be a ton of work.


(I present these things largely as brainstorming; if I can plant the 
idea in the back of your mind or advocate for the priority thing enough 
that it makes it in, that would be helpful I think.)

Evan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist4.pair.net/pipermail/scons-users/attachments/20160115/16b0894f/attachment.html>


More information about the Scons-users mailing list