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

[Eric Christopher via cfe-dev]

FWIW we've gone over this quite a bit in the past, see:

http://clang.llvm.org/UniversalDriver.html

That said I like the idea of a configuration file that can be passed on the
command line (or possibly) compiled in for a target. It should represent
things that can be overridden by command line option. This overlaps with
the stuff that Renato has talked about as well. For the time being command
line options are a good way of solving this and possibly just taking a
configurable response file could work for "use these options on every
compile". I'd want to see what it looks like, but could be an incremental
start.

-eric

On Thu, Oct 15, 2015 at 1:13 PM James Y Knight <jyknight at google.com> wrote:

> On Thu, Oct 15, 2015 at 3:22 PM, Renato Golin <renato.golin at linaro.org>
> wrote:
>
>> Your use case is not what people are used to expect, so any change in
>> that direction is not "trivial". Beyond code changes, there are other
>> architectures and tools to think about.
>
>
> I'm very confused by the statement "is not what people are used to
> expect"? Being able to configure the default abi/isa for your system, via
> changing compile-time options of gcc, is what people are used to doing,
> right? So I thought my use case exactly *is* what people are used to
> expecting?
>
> For five years this issue has been completely ignored, and now
>> suddenly there's a lot of pressure to get it working ASAP. While I
>> welcome people noticing one of my first proposals to LLVM, that was
>> meant to fix the driver, not make it even more unpalatable.
>
>
> I have no personal immediate need to solve this problem, but I keep seeing
> a lot of different people dancing around the same issue, so I do actually
> think it's about time to solve it even if nobody has done so for 5 years. I
> also wasn't paying much attention to llvm 5 years ago, so I don't really
> know what people said or did back then. :) So, yes, let's fix it now, while
> people are actually interested and talking about it.
>
> There are other threads that also expose some changes that need to be
>> done in the libraries, so we need to take them all into consideration
>> before taking any rushed decision.
>
>
> I don't know at all what you mean by that.
>
>
> Anyways, sure, writing a python/perl/shell clang driver-driver would be
> one way to demonstrate the viability of the idea. But, so would writing a
> change to the actual driver. Again, I don't think the actual code change
> here will be very complicated.
>
> The main thing I thought would be a hurdle was having people agree that
> any sort of local configurability of the clang driver was a good idea. But
> that seems to actually not be controversial. So, what's needed seems just a
> matter of hashing out some details. And (maybe I'm missing something
> fundamental?) it doesn't seem like there's even a huge amount of details to
> worry about here.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20151016/561df645/attachment.html>