From owner-freebsd-bugs@FreeBSD.ORG Thu Mar 6 10:32:46 2008 Return-Path: Delivered-To: freebsd-bugs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D34C71065672; Thu, 6 Mar 2008 10:32:46 +0000 (UTC) (envelope-from kris@FreeBSD.org) Received: from weak.local (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 9CBC58FC12; Thu, 6 Mar 2008 10:32:41 +0000 (UTC) (envelope-from kris@FreeBSD.org) Message-ID: <47CFC848.9060300@FreeBSD.org> Date: Thu, 06 Mar 2008 11:32:40 +0100 From: Kris Kennaway User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) MIME-Version: 1.0 To: jau@iki.fi References: <200803060509.m2659N0C085966@jau.iki.fi> In-Reply-To: <200803060509.m2659N0C085966@jau.iki.fi> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Remko Lodder , freebsd-bugs@FreeBSD.org Subject: Re: kern/121292: FreeBSD-7.0 kernel build fails on FreeBSD-6.3 X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2008 10:32:46 -0000 Jukka A. Ukkonen wrote: > Quoting Remko Lodder: >> Kris is not wrong here, you are confused ;) > > Entirely correct. I was confused. > > Anyhow my custom kernels have always been (and probably always > will be) based on generic and almost invariably only adding > things which are not default parts of generic. > The problem was a missing "device wlan_amrr" line which I had > skipped by accident while merging my older 6.3 custom config > and 7.0 generic. > > Previously parallel make has not let the potential error > messages roll several hundreds of lines out of a 50 line > xterm window but given up very quickly after an error. I guess you've been lucky, it's always worked this way. > For some reason this time any alleged error messages managed > to speed out of the xterm buffer completely. > Recording the whole build to a typescript file will apparently > be necessary in the future. > > This experience anyhow raised a question as well. > Should there be some sort of dependency checking added to > kernel builds such that any missing features were implicitly > included if other explicitly configured features depend on > them? > Such an extension could also make a point of informing the > poor fool building the kernel - in this case that would have > been me - of the features that need to be implicitly included > as dependencies. People occasionally float the idea of doing this, but no-one has come up with a suitable implementation. Kris