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

[Daniel Sanders via cfe-dev]

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

I can see the overlap between this and that. If I understand correctly, it's trying to take a JIT's ability to know exactly what the target hardware is and use that to drive normal compilation. For my case, I want the target to be what the distribution wants it to be (which is often a subset of the actual hardware) but both cases require the same ability to modify the target based on a configuration.

> -----Original Message-----
> From: cfe-dev [mailto:cfe-dev-bounces at lists.llvm.org] On Behalf Of Daniel
> Sanders via cfe-dev
> Sent: 15 October 2015 11:51
> To: Renato Golin; Eric Christopher; cfe-dev at lists.llvm.org
> Cc: Marshall Clow; Jonathan Roelofs
> Subject: Re: [cfe-dev] Small patches to allow fully independent
> clang/llvm/compiler-rt/libc++
> 
> 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.
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev