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>