Date: Wed, 27 Feb 2013 17:59:52 -0600 From: Brooks Davis <brooks@freebsd.org> To: "Simon J. Gerraty" <sjg@juniper.net> Cc: freebsd-arch@freebsd.org Subject: Re: [RFC] external compiler support Message-ID: <20130227235952.GE19594@lor.one-eyed-alien.net> In-Reply-To: <20130227232632.74C2F58096@chaos.jnpr.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>
next in thread | previous in thread | raw e-mail | index | archive | help
--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--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20130227235952.GE19594>