From owner-freebsd-arch@FreeBSD.ORG Wed Feb 27 23:28:21 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 4B34FA42; Wed, 27 Feb 2013 23:28:21 +0000 (UTC) (envelope-from sjg@juniper.net) Received: from exprod7og119.obsmtp.com (exprod7og119.obsmtp.com [64.18.2.16]) by mx1.freebsd.org (Postfix) with ESMTP id 0DC88A2C; Wed, 27 Feb 2013 23:28:20 +0000 (UTC) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob119.postini.com ([64.18.6.12]) with SMTP ID DSNKUS6Wk0QVvHslgJusApkdR9RBSaZXN6jG@postini.com; Wed, 27 Feb 2013 15:28:21 PST Received: from magenta.juniper.net (172.17.27.123) by P-EMHUB02-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.3.213.0; Wed, 27 Feb 2013 15:26:33 -0800 Received: from chaos.jnpr.net (chaos.jnpr.net [172.24.29.229]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id r1RNQW356767; Wed, 27 Feb 2013 15:26:32 -0800 (PST) (envelope-from sjg@juniper.net) Received: from chaos.jnpr.net (localhost [127.0.0.1]) by chaos.jnpr.net (Postfix) with ESMTP id 74C2F58096; Wed, 27 Feb 2013 15:26:32 -0800 (PST) To: Brooks Davis Subject: Re: [RFC] external compiler support In-Reply-To: <20130227220520.GB19594@lor.one-eyed-alien.net> References: <20130227003517.GB7348@lor.one-eyed-alien.net> <28404C12-67F3-44F0-AB28-02B749472873@bsdimp.com> <51BB3E17-128A-4989-B272-D8B40D4B854B@bsdimp.com> <20130227175006.A604A58096@chaos.jnpr.net> <20130227195807.GA19255@lor.one-eyed-alien.net> <20130227202822.8F53B58096@chaos.jnpr.net> <20130227220520.GB19594@lor.one-eyed-alien.net> Comments: In-reply-to: Brooks Davis message dated "Wed, 27 Feb 2013 16:05:20 -0600." From: "Simon J. Gerraty" X-Mailer: MH-E 7.82+cvs; nmh 1.3; GNU Emacs 22.3.1 Date: Wed, 27 Feb 2013 15:26:32 -0800 Message-ID: <20130227232632.74C2F58096@chaos.jnpr.net> MIME-Version: 1.0 Content-Type: text/plain Cc: freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2013 23:28:21 -0000 On Wed, 27 Feb 2013 16:05:20 -0600, Brooks Davis writes: >I like the end goal, but it doesn't feel like taking this route gets me >any less code in Makefile.inc1 in the short term. Makefile.inc1 are perhaps necessary for the short term. I'm not using them at all, but also not yet building the entire universe. >I don't like that for now it forces me to use traditional names for >all these tools (they must match the name of the native tools) and to >install them next to each other (or create a link farm to do that). Sorry, I might be caffeine deficient, can you elabortate? I don't see how that follows. Anything done via *.mk can be overridden via Makefile.inc1 and if need be you can always use extra variables. >This seems to make it unnecessarily difficult to perform any kind of >casual compiler testing across the whole tree. You are presumably wanting to separately control the basename of the compiler as well as its location ? Separate variables? Presumably by changing compiler you also need to control CFLAGS... eg. I found it necessary to add CFLAGS_LAST.clang += -isystem ${STAGE_OBJTOP}/usr/include/clang/3.2 CXXFLAGS_LAST += ${CFLAGS_LAST.${COMPILER_TYPE}} You could get carried away with indirection... CLANG_NAME?= clang32 GCC_NAME?= gcc42 COMPILER_TYPE.c ?= gcc COMPILER_TYPE.cc ?= clang COMPILER.c ?= ${${COMPILER_TYPE.c:tu}_NAME} CC ?= ${COMPILER_PATH.${COMPILER.c}}${COMPILER.c} which lets you indivitually control the type of compiler its name is path etc >> >Otherwise /rescue fails as do several things in /boot. >>=20 >> That would presumably be bugs in the relevant makefiles no? > >The problem in both cases is that they need tight control of C(XX)FLAGS >in order to generate small or static binaries. There are any number Again can you elaborate - I just took a quick look and didn't see anything under rescue/ that wasn't a simple addition to CFLAGS. >Making the options part of CC works today and avoids needing to modify >many makefiles whose products I can't test easily or in many cases at >all. Notionally I feel it's equivalent to creating a wrapper script >around each tool to change a couple defaults without the overhead or >hassle. So long as you don't have to do it via Makefile.inc1 that may be so. >While I could test the /rescue case, fixing it involves modifying >cruchgen and my first attempt to look at it lead me to run away quickly. :) I'm obviously missing something, so before you dive into that let's get on the same page ;-)