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
>> 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.

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.


Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail

Reply via email to