[RFC] external compiler support

[Brooks Davis]

On Wed, Feb 27, 2013 at 09:08:05AM -0700, Warner Losh wrote:
> Ooops, forgot to add one item..
> 
> 
> On Feb 27, 2013, at 8:57 AM, Warner Losh wrote:
> 
> > 
> > On Feb 26, 2013, at 5:35 PM, Brooks Davis wrote:
> > 
> >> Below (and at http://people.freebsd.org/~brooks/patches/xcc.diff) you
> >> can find an initial patch with proposed commit for external compiler
> >> support.  It relies on the existing cross binutils as I'm finding that
> >> the two are fairly separable.  With this patch I've been able to build
> >> from amd64 to arm, amd64, and i386 using clang from the lang/clang-devel
> >> port.  I've also compiled the tree with a customized clang being
> >> developed at the University of Cambridge.
> > 
> > Cool!
> > 
> >> The patch is untested with gcc.
> > 
> > I'd like to see it tested with gcc :)
> > 
> >> Does this seem like a reasonable approach?  I do plan to look at external
> >> binutils support, but it's not on the critical path for our current work
> >> so I've opted to avoid it for now.
> > 
> > The patches I posted a few months ago had that as well...
> > 
> >> As a bonus for those who don't need an external compiler, but do run
> >> make buildworld frequently, the XCC, XCXX, and XCPP variables can be set
> >> to the location of the installed base system compiler to avoid building
> >> the compiler twice during buildworld.
> > 
> > I think this will work, but it is kludgy.  I had created a __X=<prefix-path> which was prepended to ${CC}, et al, in sys.mk. It was only defined when you set CROSS_COMPILER_PATH (or EXTERNAL_COMPILER_PATH, I forget) during the cross building stage. It also had the advantage of making external cross binutils available. Your patch could fairly easily use this interface instead of having to set 3 different variables, which will morph to 10 when you add binutil support.
> 

I think something like this will have to be done for binutils given the
way -B works, but I don't think it's workable in the general compiler
case because I want to be able to use gcc46 or a future clang33 or
similar as CC without changing the system compiler.  Ideally I'd
also like to support clang's method of finding appropriate binutils
by looking first for /binutils/path/${TARGET_TRIPLE}-tool and then
/binutils/path/tool.

As a strawman, let's say we add a CROSS_COMPILER_PATH and a
CROSS_BINUTILS_PATH.  The former will set XCC, XCXX, and XCPP if they
are unset.  The latter will control -B and set the various binutils
variables (XNM, XLD, etc).

The sys.mk solution seems clean at first glance, but I don't think it's
sufficently general.  It's also insufficient because you need --sysroot
unless you want to build a sysroot somewhere and hardcode paths to it
into your toolchain.  Worse, if you want rescue to work, --sysroot must
be part of CC etc because crunchgen doesn't make it easy to manipulate
CFLAGS.

> I've also started looking into using clang --mumble to doing cross builds too, so I don't have to have 4 compilers configured and laying around for the different platforms I play with.  That isn't reflected in the port.
> 

I'm not sure what you mean by "That isn't reflected in the port".

-- Brooks
-------------- 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/88d6615d/attachment.sig>