Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 27 Feb 2013 14:47:59 -0700
From:      Warner Losh <imp@bsdimp.com>
To:        Brooks Davis <brooks@FreeBSD.org>
Cc:        freebsd-arch@FreeBSD.org
Subject:   Re: [RFC] external compiler support
Message-ID:  <1CC1DB5A-E87A-456C-AD2C-E203146BB736@bsdimp.com>
In-Reply-To: <20130227214445.GA19594@lor.one-eyed-alien.net>
References:  <20130227003517.GB7348@lor.one-eyed-alien.net> <28404C12-67F3-44F0-AB28-02B749472873@bsdimp.com> <51BB3E17-128A-4989-B272-D8B40D4B854B@bsdimp.com> <20130227190804.GB17489@lor.one-eyed-alien.net> <13FB8CB0-9937-4BD8-AE89-0D24494D8663@bsdimp.com> <20130227214445.GA19594@lor.one-eyed-alien.net>

next in thread | previous in thread | raw e-mail | index | archive | help

On Feb 27, 2013, at 2:44 PM, Brooks Davis wrote:

> On Wed, Feb 27, 2013 at 02:01:42PM -0700, Warner Losh wrote:
>>=20
>> On Feb 27, 2013, at 12:08 PM, Brooks Davis wrote:
>>=20
>>> On Wed, Feb 27, 2013 at 09:08:05AM -0700, Warner Losh wrote:
>>>> Ooops, forgot to add one item..
>>>>=20
>>>>=20
>>>> On Feb 27, 2013, at 8:57 AM, Warner Losh wrote:
>>>>=20
>>>>>=20
>>>>> On Feb 26, 2013, at 5:35 PM, Brooks Davis wrote:
>>>>>=20
>>>>>> 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.
>>>>>=20
>>>>> Cool!
>>>>>=20
>>>>>> The patch is untested with gcc.
>>>>>=20
>>>>> I'd like to see it tested with gcc :)
>>>>>=20
>>>>>> 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.
>>>>>=20
>>>>> The patches I posted a few months ago had that as well...
>>>>>=20
>>>>>> 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.
>>>>>=20
>>>>> I think this will work, but it is kludgy.  I had created a =
__X=3D<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.
>>>>=20
>>>=20
>>> 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.
>>=20
>> I didn't know that clang did this, but that's certainly doable.
>=20
> The key is that for it to work we need to set each tool's name
> individually.
>=20
>>> 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).
>>=20
>> I'm not sure I like splitting things like that. It is unnatural.
>=20
> 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.
>=20
> 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).
>=20
> 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?=3D${CROSS_TOOLCHAIN_PATH}
CROSS_BINUTILS_PATH?=3D${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.

Warner=



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1CC1DB5A-E87A-456C-AD2C-E203146BB736>