From owner-freebsd-current@FreeBSD.ORG Sat Aug 21 21:54:11 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 86DE610656A5; Sat, 21 Aug 2010 21:54:11 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id 450D58FC16; Sat, 21 Aug 2010 21:54:10 +0000 (UTC) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id 96AA11FFC34; Sat, 21 Aug 2010 21:54:09 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id 498BD8454D; Sat, 21 Aug 2010 23:54:09 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Nathan Whitehorn References: <201008190304.o7J34Wa4089466@freebsd-current.sentex.ca> <86occzdmhg.fsf@ds4.des.no> <4C6D557E.6080406@freebsd.org> <86sk29ws6u.fsf@ds4.des.no> <4C6E825C.5060509@freebsd.org> <86fwy9f5vj.fsf@ds4.des.no> <4C6F0813.9030007@freebsd.org> Date: Sat, 21 Aug 2010 23:54:08 +0200 In-Reply-To: <4C6F0813.9030007@freebsd.org> (Nathan Whitehorn's message of "Fri, 20 Aug 2010 17:56:19 -0500") Message-ID: <86aaofpr7j.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: powerpc@freebsd.org, FreeBSD Tinderbox , current@freebsd.org Subject: Re: [head tinderbox] failure on powerpc64/powerpc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Aug 2010 21:54:11 -0000 Nathan Whitehorn writes: > I'm the first to admit that many of the config tricks involved in this > port, and GENERIC64, are ugly hacks, largely because config(8) was not > designed with such things in mind. It's not just "config tricks and ugly hacks", it also violates the assumption that target names are unique. > To address the immediate problem, I think the best solution is to use > the -m option to config to reject kernel configs for different > architectures, I'm not sure I understand what you mean (or rather, how it would help the tinderbox). What *would* help would be an easy way to determine, *before* trying to build it, whether a specific kernel config is appropriate for a specific target. Can you think of an easier way to do this than to scan the config for the "machine" line? DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no