Re: MAKE_JOBS_SAFE=[number]

[David Holland <dholland-pkgtech%netbsd.org@localhost>]

On Sun, Sep 23, 2012 at 11:26:37AM +0200, Marc Espie wrote:
 > >  > Agreed.  If the software fails to build with any degree of
 > >  > parallelization greater than 1, the Makefiles are bogus.  As with
 > >  > threading bugs, it's just a matter of time before the problem appears.
 > > 
 > > It's not that simple. It's not like thread scheduling in C code, where
 > > the timeslices and variances caused by the scheduler are much larger
 > > than individual actions or blocks of code.
 > > 
 > > In a build, the amount of time each target takes may scale with your
 > > processor speed (or not) but is mostly going to be roughly the same
 > > each time and (more importantly) roughly the same each time with
 > > respect to how long other targets take. Also, make dispatches the
 > > targets in the same or nearly the same order each time; it is not
 > > random.
 > 
 > That's not quite true. It massively depends on your hardware and setup,
 > processor speed, number of cores, IO speed may vary widely.  In my
 > experience, nearly clean Makefiles may suddenly start to break when a new
 > setup appears.

At least with current tools, if the build is limited to e.g. 8 jobs,
and you add more cores beyond 8, there should be no effect. And also,
the relative time taken by compile jobs tends to scale with hardware
performance.

As I already said, obviously it's better to fix the makefiles.

 > Actually, yacc runs are often a problem. A lot of people out there do not
 > understand make, and they think that:
 > 
 > file.c file.h:       file.y
 >      some yacc rule
 > 
 > is going to work.
 > 
 > Not so, since that expands to two separate targets, and yacc may very well
 > be generating file.c while file.h is being used elsewhere. Oops.

This issue is the subject of periodic flamewars, because even though
the label on bmake's koolaid packets says what you've described, the
historical and traditional make behavior is that what you've cited is
in fact a correct yacc rule.

See for example <20110607164857.GB22062%netbsd.org@localhost> in tech-toolchain.

-- 
David A. Holland
dholland%netbsd.org@localhost