RFT: Please help testing the llvm/clang 3.5.0 import
Warner Losh
imp at bsdimp.com
Thu Dec 18 14:51:58 UTC 2014
> On Dec 18, 2014, at 7:44 AM, Dimitry Andric <dim at FreeBSD.org> wrote:
>
> On 18 Dec 2014, at 14:34, Robert Huff wrote:
>> Dimitry Andric writes:
>>
>>>> - Could a "MK_CLANG_ALL_TARGETS" or something similar option be
>>>> added to src.opts.mk to fine tune this process for those of us who
>>>> don't want to build a cross-compile toolchain every iteration for our
>>>> target MACHINE/MACHINE_ARCH?
>>>
>>> I would be fine with something like this, as long as it is turned off by
>>> default, or if it is only used for the bootstrap stages. It is actually
>>> an extremely useful feature of clang that you can target multiple
>>> architectures with one compiler binary.
>>
>> Point of information: this seems useful for developers, and
>> (almost entirely) useless for everyone else. Are there other
>> cohorts that want this badly?
>> If that's correct, and there's a simple switch for
>> configuration ... why should this default to what's useful for the
>> (much?) smaller number of people? About what am I ignorant?
>
> It's not a simple switch, at least not now. If you use the upstream
> build system for llvm, e.g. autoconf or CMake, it has an option to
> select all the architectures that are supported. Several config files
> are then generated differently, and parts of the target support
> subdirectories are selectively enabled or disabled.
>
> In fact, we already build just a subset of the available architectures,
> since FreeBSD only supports about 5 of them. We can probably arrange
> for a more minimal configuration in our build system, but since the
> build time saved is quite small, I don't think it makes much sense in
> complicating our build system even further.
>
> If people are really so interested in shaving off a little, for more
> complication, that is fine with me. But unfortunately, I have too many
> tasks on my plate right now, and I cannot work on it. Besides, doing
> such a new feature now would interfere with the current branch work.
With the recent parallelism work, the is true. It might save a couple percent
off the build time. Before those changes, though, disabling all non target
arches saved about 10% of the buildworld time.
Creating a hack to do this is easy (which is how I measured it). But Dimitry
is right that creating a robust solution is hard. Even harder if you want it
to be completely clean.
> Also, after the 3.5.0 import, there are much more interesting fish to
> fry, in my opinion. For example, importing newer versions of libc++ and
> compiler-rt, which can bring address sanitizer support, etc.
I tend to agree. IMHO, supporting the work going on to bring the
meta-mode stuff will pay far higher dividends than optimizing this
corner of the build.
Warner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.freebsd.org/pipermail/freebsd-current/attachments/20141218/123ba34e/attachment.sig>
More information about the freebsd-current
mailing list