From owner-freebsd-arch@FreeBSD.ORG Wed Feb 27 23:59:53 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 A72E5DB7 for ; Wed, 27 Feb 2013 23:59:53 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (lor.one-eyed-alien.net [69.66.77.232]) by mx1.freebsd.org (Postfix) with ESMTP id 8617AB0D for ; Wed, 27 Feb 2013 23:59:52 +0000 (UTC) Received: from lor.one-eyed-alien.net (localhost [127.0.0.1]) by lor.one-eyed-alien.net (8.14.5/8.14.5) with ESMTP id r1RNxrvf020807; Wed, 27 Feb 2013 17:59:53 -0600 (CST) (envelope-from brooks@lor.one-eyed-alien.net) Received: (from brooks@localhost) by lor.one-eyed-alien.net (8.14.5/8.14.5/Submit) id r1RNxqd4020806; Wed, 27 Feb 2013 17:59:52 -0600 (CST) (envelope-from brooks) Date: Wed, 27 Feb 2013 17:59:52 -0600 From: Brooks Davis To: "Simon J. Gerraty" Subject: Re: [RFC] external compiler support Message-ID: <20130227235952.GE19594@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> <20130227232632.74C2F58096@chaos.jnpr.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="EXKGNeO8l0xGFBjy" Content-Disposition: inline In-Reply-To: <20130227232632.74C2F58096@chaos.jnpr.net> User-Agent: Mutt/1.5.21 (2010-09-15) 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:59:53 -0000 --EXKGNeO8l0xGFBjy Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Feb 27, 2013 at 03:26:32PM -0800, Simon J. Gerraty wrote: >=20 > 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. >=20 > Makefile.inc1 are perhaps necessary for the short term. > I'm not using them at all, but also not yet building the entire > universe. >=20 > >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). >=20 > 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. If I need to override CC or the like in Makefile.inc1 then all this indirection buys me nothing since I immediately throw it away. As things stand I can't override them at all because the ${CC} we use to build host tools must be the same as the one we use to cross build. We currently contrive to make that work by unconditionally stuffing a cross compiler into ${WORLDTMP}. My patches mostly exist to break that tie between the two ${CC}s. I'm not arguing against the proposed indirection at all. The long term benefits are quite clear, it just doesn't do me much good in the current world order. > >This seems to make it unnecessarily difficult to perform any kind of > >casual compiler testing across the whole tree. >=20 > You are presumably wanting to separately control the basename of the > compiler as well as its location ? Yes. It's not critical, but it would be nice to make it easy for people to do this sort of thing. > Separate variables? > Presumably by changing compiler you also need to control CFLAGS... > eg. I found it necessary to add >=20 > CFLAGS_LAST.clang +=3D -isystem ${STAGE_OBJTOP}/usr/include/clang/3.2 > CXXFLAGS_LAST +=3D ${CFLAGS_LAST.${COMPILER_TYPE}} Hmm, I've not had to do that, but it seems likely that similar things could be required. > You could get carried away with indirection... >=20 > CLANG_NAME?=3D clang32 > GCC_NAME?=3D gcc42 >=20 > COMPILER_TYPE.c ?=3D gcc > COMPILER_TYPE.cc ?=3D clang >=20 > COMPILER.c ?=3D ${${COMPILER_TYPE.c:tu}_NAME} >=20 > CC ?=3D ${COMPILER_PATH.${COMPILER.c}}${COMPILER.c} >=20 > which lets you indivitually control the type of compiler its name is > path etc=20 >=20 > >> >Otherwise /rescue fails as do several things in /boot. > >>=3D20 > >> 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 >=20 > Again can you elaborate - I just took a quick look and didn't see=20 > anything under rescue/ that wasn't a simple addition to CFLAGS. I think remember the issue now. The problem was that I was setting a variable (SYSROOT) that would cause additions to CFLAGS. Because the crunch environment is set by crunchgen I wasn't able to figure out a good way to pass that variable in such that changes were made to CFLAGS. That may well be a lack of imagination or understanding of the combination of bsd.crunchgen.mk and crunchgen, but it wasn't at all clear how to even get started. An example of a problem boot related Makefile is sys/boot/i386/gptboot/Makefile. -- Broks --EXKGNeO8l0xGFBjy Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iD8DBQFRLp34XY6L6fI4GtQRAq1zAJsEzU2jCHzSHrde06SNGbU3rm20hQCeJ68Q 7Y1azPwTI0uoFPEQgUPXxvU= =XnZa -----END PGP SIGNATURE----- --EXKGNeO8l0xGFBjy--