[RFC] external compiler support

[Brooks Davis]

On Wed, Feb 27, 2013 at 03:26:32PM -0800, Simon J. Gerraty wrote:
> 
> 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.

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.
> 
> 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
> 
> CFLAGS_LAST.clang += -isystem ${STAGE_OBJTOP}/usr/include/clang/3.2
> CXXFLAGS_LAST += ${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...
> 
> 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.

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 188 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-arch/attachments/20130227/579b059a/attachment.sig>