[cfe-dev] Small patches to allow fully independent clang/llvm/compiler-rt/libc++

[Eric Christopher via cfe-dev]

> #1 You are furiously against supporting clang which uses compiler-rt,
> libc++ etc by default? Compiler-rt and the ability to build a non-gnu
> toolchain by DEFAULT is such a worthless idea that it has no value at all,
> right?
>

Please avoid doing this. You are intentionally misconstruing what I said in
a way to be inflammatory.

I also already support a clang that uses compiler-rt and libc++ by default.
This is the default case of the darwin targeting side of clang. Doing this
in a way such that generic distributors can specify things is harder versus
just changing the defaults for a toolchain.

As far as your patches, there's some support for the top level for doing a
similar thing. See the LLVM_DEFAULT_TARGET_TRIPLE bits. That involves
resetting what it thinks the current host is to something else that then
gets normalized, etc. It's a bit of work and honestly not the way I'd like
to go about it. I wasn't hugely in favor of the patch in the first place,
but it was somewhat useful from a compatibility argument for existing build
systems where they're dependent on things like mips-elf-gcc being the
compiler and the way it's invoked.

For what sounds to be an OS that has these as set defaults I think we
should enable this set of defaults in the driver (ala what Jonathan and
Vasileios said) and cross compiling to that OS should be as simple as using
the appropriate target yes? For native code it would work the same way. I'm
curious what issues you're seeing with this sort of approach? What use
cases you're seeing?


>
> #2 we love flags and can't get enough of them..
>

I'm not sure what you mean here.


> ----
> I don't know why anyone even talks about QA or runtime options.
>

Because they're important? I'm not sure what your objection here is either.


> My patch does NOT or should not introduce new stuff. If your bot doesn't
> build compiler-rt today.. well it won't be enabled tomorrow.. I'm not
> proposing to remove flags or driver capability.. I'm proposing to allow a
> compile time option to set defaults..
>
> Please stick to discussing this very specific issue. ‎Apologies if my tone
> is off
>

We've been doing nothing but talking about your issue, the design, and the
code the entire time.

-eric
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20151014/01679648/attachment.html>