From owner-svn-src-all@FreeBSD.ORG Tue Dec 17 17:55:15 2013 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A8137A27; Tue, 17 Dec 2013 17:55:15 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 7B1FC1C7F; Tue, 17 Dec 2013 17:55:15 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 75E16B972; Tue, 17 Dec 2013 12:55:14 -0500 (EST) From: John Baldwin To: "Dag-Erling =?utf-8?q?Sm=C3=B8rgrav?=" Subject: Re: svn commit: r259010 - in head/sys: conf powerpc/fpu Date: Tue, 17 Dec 2013 12:20:46 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.4-CBSD-20130906; KDE/4.5.5; amd64; ; ) References: <201312052149.rB5LnEcT011811@svn.freebsd.org> <201312131231.04749.jhb@freebsd.org> <86k3f4kjk8.fsf@nine.des.no> In-Reply-To: <86k3f4kjk8.fsf@nine.des.no> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <201312171220.47075.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 17 Dec 2013 12:55:14 -0500 (EST) Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Dec 2013 17:55:15 -0000 On Monday, December 16, 2013 8:32:39 am Dag-Erling Sm=C3=B8rgrav wrote: > John Baldwin writes: > > Dag-Erling Sm=C3=B8rgrav writes: > > > John Baldwin writes: > > > > LINT64 is yet another kernel config covered by 'make tinderbox', > > > > but not by the periodic tinderbox. It is probably worth adding to > > > > the periodic tinderbox (someday it'd be nice if the two > > > > tinderboxes built the same set of things). > > > Some day it would be nice if people talked to me directly instead of > > > sniping from the sidelines. > > Ah, but when people have raised this exact issue before (that tcbuild > > and 'make tinderbox' build different things), you have blown them off > > repeatedly. >=20 > I have no idea what tcbuild is. I meant it as the name of your scripts (probably have ports-mgmt/tinderbox = on=20 the brain too much). > I blow people off when they complain that the tinderbox doesn't work > exactly like 'make tinderbox' because it's not intended to. I just want it to build the same things and report errors when they are=20 broken. In that sense they should both do the same thing. > > > Oh, and 'make tinderbox' should die. > > No, it is very developer friendly as it Just Works(tm) as a single > > command from an existing source tree checkout. >=20 > We already had 'make universe'. >=20 > The story behind 'make tinderbox' is that Alfred threw a fit over a > tinderbox breakage and insisted, despite being provided with ample proof > to the contrary, that my tinderbox was a black box which nobody knew how > worked and nobody could reproduce and that tinderbox reports were > therefore worthless. He then proceeded to implement 'make tinderbox' > purely to piss me off. It serves no other purpose and needs to die. Ah, a bit touchy I see. While that might have been Alfred's initial motivation, the points still remain that: 1) 'make tinderbox' Just Works as a single command from an existing source tree checkout. I don't have to track down some other thing from some other SVN tree to checkout and configure. It's also easy to reproduce a single failed build step in the same tree by doing 'make buildkernel' etc. so I can fix an issue that pops up and do quick turnaround testing and do a final 'make tinderbox' to make sure all is still well. 2) 'make tinderbox' provides a summary of what failed. 'make universe' does not. You have to go check all the log files by hand to see if anything failed. That is less helpful. It definitely serves a useful purpose for many developers, and I for one don't sit and cackle maniacally while rubbing my hands each time I invoke it because I think that somehow my doing so is pissing you off. > > It also happens to build more of the tree than the periodic tinderbox > > (by building more kernel configs, albeit doing quite a bit of > > duplicate work for platforms like arm in the process). >=20 > That's simply not true. The tinderbox builds exactly the same kernels > as 'make tinderbox' if they're present. The issue here is that a bug in > the source tree prevents some of these kernel configurations from being > generated, hence the tinderbox cannot build them. Ah, I thought at one point it only built GENERIC and LINT type configs, but presumably that has changed? As long as they build the same things I'm happy. I just want to avoid running into unrelated breakages when I do a 'make tinderbox' on a patched tree (the unrelated breakage thing is what I recently ran into with LINT64). =2D-=20 John Baldwin