Re: RFT: Please help testing the llvm/clang 3.5.0 import

> 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