[RFC] external compiler support

[Brooks Davis]

On Wed, Feb 27, 2013 at 02:01:42PM -0700, Warner Losh wrote:
> 
> On Feb 27, 2013, at 12:08 PM, Brooks Davis wrote:
> 
> > 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.
> 
> I didn't know that clang did this, but that's certainly doable.

The key is that for it to work we need to set each tool's name
individually.

> > 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).
> 
> I'm not sure I like splitting things like that. It is unnatural.

That's the traditional view with lots of historic merit.  At least in
the short term it's not a useful view for me.  I want to be able to
use our existing infrastructure to build a cross binutils and then use
it with an external compiler.  In a clang world, we currently have one
compiler and many binutils unless we gratuitously build many compilers
as the FreeBSD build system currently does.  Some day we will likely have
an all-llvm toolchain available and then we will have one toolchain for
all supported architectures.

I suppose could hack what I want to do into the traditional single
toolchain world view by build a mips64 xdev toolchain and then building
a linkfarm and/or set of wrapper scripts to it and the clang I want to
include, but that seems problematic from a reproducability perspective
(not to mention performance if I need wrappers to set -B).

Having a CROSS_TOOLCHAIN_PATH path that sets both would probably be a
useful compromise in this regard.

-- 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/1dd9e806/attachment.sig>