<div dir="ltr">FWIW we've gone over this quite a bit in the past, see:<div><br></div><div><a href="http://clang.llvm.org/UniversalDriver.html">http://clang.llvm.org/UniversalDriver.html</a><br></div><div><br></div><div>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.</div><div><br></div><div>-eric</div></div><br><div class="gmail_quote"><div dir="ltr">On Thu, Oct 15, 2015 at 1:13 PM James Y Knight <<a href="mailto:jyknight@google.com">jyknight@google.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, Oct 15, 2015 at 3:22 PM, Renato Golin <span dir="ltr"><<a href="mailto:renato.golin@linaro.org" target="_blank">renato.golin@linaro.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Your use case is not what people are used to expect, so any change in<br>
that direction is not "trivial". Beyond code changes, there are other<br>
architectures and tools to think about.</blockquote><div></div></div><br></div></div><div dir="ltr"><div class="gmail_extra">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?</div></div><div dir="ltr"><div class="gmail_extra"><br></div><div class="gmail_extra"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span style="font-size:12.8000001907349px">For five years this issue has been completely ignored, and now<br></span><span style="font-size:12.8000001907349px">suddenly there's a lot of pressure to get it working ASAP. While I<br></span><span style="font-size:12.8000001907349px">welcome people noticing one of my first proposals to LLVM, that was<br></span><span style="font-size:12.8000001907349px">meant to fix the driver, not make it even more unpalatable.</span></blockquote><div> </div></div></div><div dir="ltr"><div class="gmail_extra">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.</div></div><div dir="ltr"><div class="gmail_extra"><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span style="font-size:12.8000001907349px">There are other threads that also expose some changes that need to be<br></span><span style="font-size:12.8000001907349px">done in the libraries, so we need to take them all into consideration<br></span><span style="font-size:12.8000001907349px">before taking any rushed decision.</span></blockquote><div><br></div></div><div dir="ltr"><div>I don't know at all what you mean by that.</div><div><br></div><div><br></div><div>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.</div><div><br></div><div>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.</div></div>
</blockquote></div>