svn commit: r187132 - head/usr.bin/make

Dmitry Marakasov amdmi3 at
Fri Jan 30 10:36:01 PST 2009

* David O'Brien (obrien at wrote:

> > > I'm sorry I disagree.  You're complaining about something that is
> > > a feature of FreeBSD 1.x, 2.0 - 3.0, 4.4BSD, all NetBSD versions,
> > > all OpenBSD versions, Sprite, and the Open Group's Open Development
> > > Environment make.
> > 
> > Nice. Well I've been using FreeBSD since 4.7, and I don't believe I've
> > seen this once.
> Please note, FreeBSD 4.7 falls outside the FreeBSD versions I listed.

I understand. I'm saying that you can't really use "it was there
10 years ago" as an argument. I can use "it was NOT there since at
least 4.7" however, as _this is what people are used to now :)

> > Not `BSD user', but just `user'. We can't take somethink that was
> > used back in FreBSD 3.0 as common and expected thing. By least
> > astonishment I mean:
> > 
> > - I do not expect to see difference between plain make and parallel
> >   make.
> Why?  It is operating differently.  Do you expect to see any difference
> in behavior between a UP or SMP kernel?

It's only internal difference. I don't observe any changes in behaviour
other than `SMP: AP CPU #1 Launched!' in dmesg and increased performance
due to multiple cores usage. And sideeffects of SMP of course, like
garbled kernel output (kernel: seScyonncdisn)g  fdoirs kssy,s tvenmo
creesmsa i`nsiynngc.e.r.' to3  stop...0 0 done) :)
Which should be of course fixed.

> > - I do not expect extra messages
> Why doesn't all the extra output of:
>   ===> gnu/usr.bin/gperf (obj,depend,all,install)
>   ===> gnu/usr.bin/gperf/doc (obj)
>   ===> gnu/usr.bin/gperf/doc (depend)
>   ===> gnu/usr.bin/gperf/doc (all)
> bother you?  I expect the "make obj" or "make depend" step to just happen
> nicely and quietly.  But instead its there.

Those messages is the part of world building process, you may either
remove those or duplicate each 10 times, I won't say a word - those
are makefiles tweaked for the most useful output for world/kernel

But changing make is the very different case, as it affects not only
kernel/world but everything and everybody.

And, by the way, compare usefullness and readability of the quote
above and what your change does to similar output:

--- obj ---
--- _proginstall ---
sh /usr/src/tools/ -s -o root -g wheel -m 555   ctfmerge
===> games/fortune/strfile (obj,depend,all,install)
--- obj ---
--- _proginstall ---
sh /usr/src/tools/ -s -o root -g wheel -m 555   strfile
===> gnu/usr.bin/gperf (obj,depend,all,install)
--- obj ---
===> gnu/usr.bin/gperf/doc (obj)
--- obj ---
--- depend ---
===> gnu/usr.bin/gperf/doc (depend)
--- all ---
===> gnu/usr.bin/gperf/doc (all)

> > - I do not expect behaviour change compared to previous version
> Eh?  Software has 100,000's of behavior changes between versions.

Useful and non-annoying ones, mostly, otherwise there's always arguing.

> > Remember, make is not only used in FreeBSD kernel, but also in ports
> > (I know -j is not widely used there, but I believe it will someday)
> I don't believe it will happen - I've had patches to add -j to ports
> build for a long time, there has been very minimal interest in them.
> The answer there has aways to be build multiple ports at the same time.
> And so many ports aren't tested for '-j' builds it is naive to think the
> vast majority of ports would build with '-j'.  (my patch was an opt-in
> for large things like gcc)

Building multiple ports in parallel is indeed more effective, but as far
as I know we don't have proper support for those as well (parallel
writes to pkgdb will trash it). Also, ability to building multiple
ports won't help as long as you only need to build one large port.

Actually, what we need is standartize some basic knobs for -j support in
ports, like:

# add WITHOUT_JOBS to make.conf to disallow parallel builds
# add ALLOW_JOBS to the port to allow building it in parallel
MAKE_JOBS?=	`sysctl -n kern.smp.cpus`

.if !defined(WITHOUT_JOBS) && defined(ALLOW_JOBS)

I believe after that mailtainers will start to add ALLOW_JOBS to the
ports which build successfully. Also, this may be added by default in
say,, as it always generates safe makefiles.

Dmitry Marakasov   .   55B5 0596 FF1E 8D84 5F56  9510 D35A 80DD F9D2 F77D
amdmi3 at  ..:  jabber: amdmi3 at

More information about the svn-src-head mailing list