From owner-freebsd-arch@FreeBSD.ORG Wed Feb 27 22:05:22 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 43E77B40; Wed, 27 Feb 2013 22:05:22 +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 89C41386; Wed, 27 Feb 2013 22:05:20 +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 r1RM5KKK020164; Wed, 27 Feb 2013 16:05:20 -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 r1RM5Kax020163; Wed, 27 Feb 2013 16:05:20 -0600 (CST) (envelope-from brooks) Date: Wed, 27 Feb 2013 16:05:20 -0600 From: Brooks Davis To: "Simon J. Gerraty" Subject: Re: [RFC] external compiler support Message-ID: <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> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="eJnRUKwClWJh1Khz" Content-Disposition: inline In-Reply-To: <20130227202822.8F53B58096@chaos.jnpr.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Brooks Davis , 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 22:05:22 -0000 --eJnRUKwClWJh1Khz Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Feb 27, 2013 at 12:28:22PM -0800, Simon J. Gerraty wrote: >=20 > On Wed, 27 Feb 2013 13:58:07 -0600, Brooks Davis writes: > >Adding the equivalent of Warner's ${__X} (however you spell it) doesn't > >seem to hurt anything, but it doesn't seem to help much either. You >=20 > The advantage of Warner's approach is that it can work from anywhere in > the tree rather than only from top-level. >=20 > One of my goals is that I should be able to [cross-]build bin/cat just > as easily from src/bin/cat as from top-level. > Warner's approach fits better in that regard. >=20 > There is of course a lot more needed. > Being able to add machine and even target specific flags for example. > These can be just as easily dealt with in share/mk: >=20 > # add machine/taget flags in order of least to most specific > CFLAGS+=3D ${CFLAGS.${MACHINE}} \ > ${CFLAGS.${.TARGET:T:R}} \ > ${CFLAGS.${.TARGET:T}} >=20 > etc. I also find it handy to have=20 >=20 > CFLAGS_LAST+=3D ${CFLAGS_LAST.${MACHINE}} \ > ${CFLAGS_LAST.${.TARGET:T:R}} \ > ${CFLAGS_LAST.${.TARGET:T}} >=20 > and add ${CFLAGS_LAST} to CFLAGS after Makefile has been read > so for example when you don't have proper sysroot support you can add > the equivalent of -I/tree/of/headers/include to the end of the -I list. 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. 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). This seems to make it unnecessarily difficult to perform any kind of casual compiler testing across the whole tree. > >This appears to work: > > > >--sysroot /tree/of/headers/and/libraries -B/path/to/binutils > > > >For the whole tree to build it must be part of the value of CC. >=20 > No, they just need to be part of the compiler command line. >=20 > >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 of ways to work around this, but nothing seems very clean. One could introduce yet another ???FLAGS variable that they use explicitly as part of their CFLAGS. Alternatively, one could change them to aggressively filter CFLAGS rather than replacing it. 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. 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. :) -- Brooks --eJnRUKwClWJh1Khz Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iD8DBQFRLoMfXY6L6fI4GtQRAubYAJ9njJlVIBCj69Eu9Zuu4SP859lxLgCgpB5m WkQnh6rUwnl0vubQrtAeS7A= =eObX -----END PGP SIGNATURE----- --eJnRUKwClWJh1Khz--