[RFC] external compiler support

[Brooks Davis]

On Wed, Feb 27, 2013 at 02:47:59PM -0700, Warner Losh wrote:
> 
> On Feb 27, 2013, at 2:44 PM, Brooks Davis wrote:
> 
> > 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.
> 
> Are you suggesting something like:
> 
> CROSS_COMPILER_PATH?=${CROSS_TOOLCHAIN_PATH}
> CROSS_BINUTILS_PATH?=${CROSS_TOOLCHAIN_PATH}
> 
> If so, I'd agree, that would be a very useful compromise: hits my ease of use issues, and lets you do what you need on the theory that others will likely need it too.

That's exactly what I'm thinking.

I hope a lot of the cruft in Makefile.inc1 goes away as Simon's work is
integrated, but for now I figure a little more won't hurt much...

-- 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/b078404f/attachment-0001.sig>