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

[Daniel Sanders via cfe-dev]

Apologies for not replying to the appropriate sub-threads. Outlook's conversation view is glitching badly on this thread and I can't tell where the tips of the conversation are.

James Y Knight:
> IMO, the argument that doing this sort of thing is evil and shouldn't ever be supported, and that there cannot be any distributor customization, is a dead-end.
> Distributors *need* the ability to customize this stuff in existing triples -- somehow. The same triples REALLY DO have different defaults on different systems
> ...and even on different variants of the "same" system. We don't want distributors to have to patch the source code to achieve that -- that's worst of all options.

+1. We've got to deal with this somehow and I don't think we can solve this without compromising our ideals to some degree. I want to sacrifice as little of our one-build-to-support-everything ideal as possible while still being able to solve the problems.

James Y Knight:
> So to me, the real question is not whether this is needed, but how do we let people do it in a supportable/testable way?

Absolutely. In the original form of the TargetTuple work, I was trying to achieve this by mapping ambiguous/inconsistent triples to genuinely unique names we can use for support/test/debug. Then if for example, Fedora had a problem we could ask for the tuple and use it to debug on Windows/OS X/Linux/etc. The key to this is that only the triple->tuple mapping is affected by configure-time/config-file differences. Everything else is compiled in

I felt the TargetTuple plan was a good compromise between the ideal world we want (and thought we had) and the flawed world clang lives in. However, run time config files solve the problem too and don't seem to have the same opposition as the configure-time mapping.

Eric Christopher:
> I hate saying this, but I could use some examples here. This is one of the places that Daniel and I disagreed I think, or at least things like "I have command line options" here makes sense.

There's several in the trouble with triples thread but to re-iterate a couple here:
* mips-linux-gnu is MIPS-II on Debian and MIPS32R2 on Fedora
* i386-linux-gnu is i486 or i586 on different versions of Debian and I now learn that moving to i686 is on the cards.
* mips-mti-linux-gnu has completely different sysroot layouts in the 2015.06-05 gcc toolchain (which we need for libraries) compared to 2015.01-7.

Renato:
> > How about, instead, having the clang driver read a config file?
> 
> This seems to be the preferred solution for everybody that has to deal
> with these problems, and we have already discussed this extensively.
> The problem is implementing it without disrupting everything else.
> 
> It's not impossible, but it requires a long streak of time and effort
> to do so, and this is not high enough on people's lists, even those
> that deal with it daily, to make the cut.

Getting a solution to this problem is very high on my list so I don't mind doing the work. My problems in this area are already serious and are going to get significantly worse in the near future. However, I need to deal with the backend infrastructure first since interpreting the triple  (and command line arguments) correctly doesn't help me if I can't deliver that information where it's needed.

I haven't read the Clang Configuration Manager thread yet. I'll go and read that.