From owner-svn-src-head@FreeBSD.ORG Fri Jan 30 18:36:00 2009 Return-Path: Delivered-To: svn-src-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E547F106566B; Fri, 30 Jan 2009 18:36:00 +0000 (UTC) (envelope-from amdmi3@amdmi3.ru) Received: from smtp.timeweb.ru (smtp.timeweb.ru [217.170.79.85]) by mx1.freebsd.org (Postfix) with ESMTP id 675EE8FC12; Fri, 30 Jan 2009 18:36:00 +0000 (UTC) (envelope-from amdmi3@amdmi3.ru) Received: from [213.148.20.85] (helo=hive.panopticon) by smtp.timeweb.ru with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1LSyDi-00083g-6V; Fri, 30 Jan 2009 21:36:02 +0300 Received: from hades.panopticon (hades.panopticon [192.168.0.32]) by hive.panopticon (Postfix) with ESMTP id 780E66D83; Fri, 30 Jan 2009 21:36:20 +0300 (MSK) Received: by hades.panopticon (Postfix, from userid 1000) id 075CF108838; Fri, 30 Jan 2009 21:36:51 +0000 (UTC) Date: Fri, 30 Jan 2009 21:36:51 +0000 From: Dmitry Marakasov To: David O'Brien Message-ID: <20090130213651.GC20856@hades.panopticon> References: <200901130653.n0D6rrNX092719@svn.freebsd.org> <20090130015518.GA20404@hades.panopticon> <20090130113402.GB92386@dragon.NUXI.org> <20090130175627.GA20856@hades.panopticon> <20090130174927.GB9615@dragon.NUXI.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20090130174927.GB9615@dragon.NUXI.org> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org Subject: Re: svn commit: r187132 - head/usr.bin/make X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jan 2009 18:36:01 -0000 * David O'Brien (obrien@freebsd.org) 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 dperso 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 build. 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/install.sh -s -o root -g wheel -m 555 ctfmerge /usr/obj/usr/src/tmp/legacy/usr/bin ===> games/fortune/strfile (obj,depend,all,install) --- obj --- --- _proginstall --- sh /usr/src/tools/install.sh -s -o root -g wheel -m 555 strfile /usr/obj/usr/src/tmp/legacy/usr/games ===> 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) MAKE_ARGS+= -j MAKE_JOBS .endif 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, cmake.mk, as it always generates safe makefiles. -- Dmitry Marakasov . 55B5 0596 FF1E 8D84 5F56 9510 D35A 80DD F9D2 F77D amdmi3@amdmi3.ru ..: jabber: amdmi3@jabber.ru http://www.amdmi3.ru