<div class="gmail_quote">On Tue, Jan 31, 2012 at 9:57 AM, Sebastian Pop <span dir="ltr"><<a href="mailto:spop@codeaurora.org">spop@codeaurora.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Tue, Jan 31, 2012 at 6:08 AM, James Molloy <<a href="mailto:james.molloy@arm.com">james.molloy@arm.com</a>> wrote:<br>
> Hi,<br>
<div class="im">><br>
>> If you are doing cross-compiling and you<br>
>> can't get the compiler name right, you have bigger issues. I still<br>
>> maintain that auto-detection like that is not only unreliable, it makes<br>
>> it a lot harder to find issues when (not if) they happen.<br>
><br>
</div><div class="im">> FWIW, I completely agree with this subpoint. It's something the target<br>
> database hopes to do - remove magic. I'm not sure what Chandler's end-game<br>
> plan is though, hopefully the same :/<br>
<br>
</div>I also agree with this point: there are toolchains that clang will never be able<br>
to guess in an automatic way.</blockquote><div><br></div><div>I actually agree on this too. ;]</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I would like clang to rely less on the current<br>

automagic detection and more on what the user is asking,</blockquote><div><br></div><div>And here is where I think the confusion arises.</div><div><br></div><div>I think that *unless* the user has told clang exactly what toolchain should be used, clang should work as hard as it can to Do The Right Thing, and produce a working binary.</div>
<div><br></div><div>That should not ever preclude empowering the user to say exactly what toolchain clang should use, where it is located, etc. Check out Rafael's patch which is improving our ability to do this with GCC-like toolchains. My hope is to build increasing support (through whatever means may be appropriate, including a database of very specific toolchain descriptions) for telling clang "use this toolchain right here" when users need that flexibility.</div>
<div><br></div><div>Does this functionality exist in a good and clear way today? Has it ever existed? Only in a very limited capacity for GCC-like toolchains, and by happenstance and fortune in a few other cases. We are working on improving that, and more contributions are, of course, welcome. I'm trying as hard as I can to review and keep up with all of the driver work going on currently. Ping me mercilessly (thanks James, looking at your patches).</div>
<div><br></div><div>I don't think the patches in question in this thread have broken any toolchain but NetBSD's, and only that one because it relied on a leaky and broken abstraction. Fixing that abstraction is a good thing, and coming up with a good and sustainable way to support the use case that NetBSD has is a good thing. The latter needs to happen on the list, with proper discussion to avoid another instance of relying on a leaky abstraction or unsustainable design construct.</div>
</div>