From owner-freebsd-current@FreeBSD.ORG Sun Jun 13 00:22:45 2010 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3B26F1065687; Sun, 13 Jun 2010 00:22:45 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 183B68FC1A; Sun, 13 Jun 2010 00:22:42 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.3/8.14.1) with ESMTP id o5CNGClF012670; Sat, 12 Jun 2010 17:16:12 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Sat, 12 Jun 2010 17:16:14 -0600 (MDT) Message-Id: <20100612.171614.561808600377024654.imp@bsdimp.com> To: dougb@FreeBSD.org From: "M. Warner Losh" In-Reply-To: <4C13F53F.3050106@FreeBSD.org> References: <4C1315F9.6000300@FreeBSD.org> <20100612.091058.242248466057850673.imp@bsdimp.com> <4C13F53F.3050106@FreeBSD.org> X-Mailer: Mew version 6.3 on Emacs 22.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org, ed@80386.nl, andreast-list@fgznet.ch Subject: Re: How to disable CLANG & co build in buildworld? 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: Sun, 13 Jun 2010 00:22:45 -0000 In message: <4C13F53F.3050106@FreeBSD.org> Doug Barton writes: : On 06/12/10 08:10, M. Warner Losh wrote: : > In message:<4C1315F9.6000300@FreeBSD.org> : > Doug Barton writes: : > : On 06/11/10 14:18, M. Warner Losh wrote: : > :> "This" is building the proper set of tools for the target. It is : > easy : > :> to do, and only a couple lines of Makefile foo in Makefile.inc1 : > :> instead of in bsd.own.mk. It is a fairly natural consequence of : > the : > :> tbemd stuff I have been working on and have started merging. : > :> : > :> The consequences today are that you build some extra tools that are : > :> only needed to build clang when in fact you aren't really going to : > be : > :> building clang. The "cost" is however long it takes to do this on : > the : > :> platform you are building on. This can range from a minute or two : > to : > :> tens of minutes depending on the power of your build system. : > : : > : Ok, obviously I'm dense because I didn't understand an answer to my : > : question anywhere in there. :) So let me try again. Why are we not : > : optimizing for the common case, where the world is built on the : > system : > : it's going to run on, which means that WITHOUT_CLANG can easily mean : > : exactly that? : > : > Because if we optimize for that case, we break the other cases. : > Broken trumps fast, so we always build the clang tools. : > : > The reason it is broke is that the default for clang varies between : > architectures, which makes the usual tests for MK_CLANG not work for : > the bootstrap tools phase. : : Sorry, still dense here. I explained it already, but I'll show the exact code... : Can you point to code where simply testing : for MK_CLANG won't work? from Makefile.inc1 # XXX: There is no way to specify bootstrap tools depending on MK-flags # with different per-architecture default values. Always build tblgen. _clang_tblgen= \ lib/clang/libllvmsupport \ lib/clang/libllvmsystem \ usr.bin/clang/tblgen coupled with: from bsd.own.mk: # # Default behaviour of MK_CLANG depends on the architecture. # .if ${MACHINE_ARCH} == "amd64" || ${MACHINE_ARCH} == "i386" || \ ${MACHINE_ARCH} == "powerpc" _clang_yes=CLANG _clang_no= .else _clang_yes= _clang_no=CLANG .endif so, if you add the test of MK_CLANG above for setting _clang_tblgen, you break the following case: neither WITH_CLANG or WITHOUT_CLANG, we go with the default: running on sparc64 (so MACHINE_ARCH=sparc64) building for i386 (so TARGET_ARCH=i386) o MK_CLANG will be 'no' o so clang's tblgen won't be built (if we added the test above you suggest) o during the build phase MACHINE_ARCH is set to i386, so clang fails later because MK_CLANG will be 'yes'. We would do extra work for the converse (building sparc64 on a i386 host), since MK_CLANG is "yes" so we build tblgen, but never use it. Since we always build tblgen, we fix this by degrading to this case. This also has no change from the typical case (amd64 or i386 built on amd64 or i386). I plan on fixing this problem, since it also applies to WITH_FDT. The root cause is that WITH_foo/WITHOUT_foo works great for optional components of the system that are basically the same everywhere (sendmail, lpr, old toolchain), but it is horrible for communicating intrinsic properties of the architecture (which is what is being done here) since there's two sets of contexts where you have to ask the question. One where TARGET_ARCH matters, and one where MACHINE_ARCH matters. While the specific examples in this case might not be too interesting, the problem it exposes is interesting to solve... Warner