bmake(1) "sometimes" honors '-j' ?

Glen Barber gjb at FreeBSD.org
Thu Feb 13 19:14:05 UTC 2014


On Thu, Feb 13, 2014 at 09:23:19AM -0800, Marcel Moolenaar wrote:
> 
> On Feb 9, 2014, at 1:36 PM, Glen Barber <gjb at FreeBSD.org> wrote:
> 
> > Maybe there is an obvious answer to this, or maybe I just do not
> > understand how computers work.
> > 
> > For snapshot builds for RPI-B and BEAGLEBONE, I am hard-coding '-j10'
> > for buildworld and '-j6' for buildkernel, because these values are
> > somewhat "safe" considering various race conditions with high '-j'
> > values.  Crochet sets the '-j' value to '1', if WORLDJOBS and
> > KERNJOBS are not set, so what I end up with is basically:
> > 'make [...] -j10 -j1 ${.TARGET}'.
> > 
> > What I see in ps(1) is a bit confusing to me, though.
> > 
> > For example, the following suggests '-j10' is being honored for the
> > 'libraries' target, but '-j1' is being forced for the 'buildworld'
> > target, and I'm not sure I understand why.  (Lines broken up for
> > readability.)
> > 
> >  root at grind:~ # ps auxww | grep make | grep 'j'
> > 
> >  root  67766    0.0  0.0  9024  1048  4  S+    7:20PM       0:03.02 make
> >  TARGET_ARCH=armv6 SRCCONF=/dev/null __MAKE_CONF=/dev/null -j10 -j 1 buildworld
> > 
> >  root  13112    0.0  0.0  9024  1488  4  S     8:24PM       0:00.94 make
> >  -j10 -f Makefile.inc1 DESTDIR=/usr/obj/arm.armv6/usr/src/tmp -DNO_FSCHG
> >  -DWITHOUT_HTML -DWITHOUT_INFO -DNO_LINT -DWITHOUT_MAN -DNO_PROFILE
> >  -DNO_TESTS libraries
> > 
> > So, if I am reading this correctly, the 'libraries' target is honoring
> > the '-j10', and 'buildworld' is honoring the later-specified '-j1'.
> > 
> > Am I reading this incorrectly, or is this something I just do not
> > understand about our toolchain?
> 
> I can't give an authoritative answer, but there are a few
> things to consider:
> 
> 1.  MAKEFLAGS is set by make(1) for later use. There's also the
>     .MAKEFLAGS variant. I don't know the *exact* difference
>     between them, but our makefile, including Makefile.inc1, uses
>     the variable and passes it to sub-makes.
> 2.  make/bmake itself sets MAKEFLAGS/.MAKEFLAGS and automatically
>     passes it to sub-makes. So when a makefile sets it, it's to
>     override the default.
> 3.  The .MAKEFLAGS variable holds the exact set of options passed
>     to make. For example:
> 	% make -j10 -j1 -V .MAKEFLAGS
> 	 -j 10 -j 1 -V .MAKEFLAGS
> 
>     What this means is that -j10 gets passed around and as such
>     can be used, not withstanding the fact that -j1 follows and
>     make itself may use that instead. Point 1 above applies.
> 
> For best results, pass only 1 -j flag or alternatively we need
> to fix our makefiles to only keep the last -j in MAKEFLAGS, etc.
> 

In this specific scenario, it was not intentional.  I had left out
a configuration entry, and the intended '-j10' was being overridden.

Anyway, thank you for the explanation.  It does make sense.

Glen

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 834 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-toolchain/attachments/20140213/0c88a66d/attachment.sig>


More information about the freebsd-toolchain mailing list