[cfe-commits] r149083 - in /cfe/trunk: include/clang/Driver/ToolChain.h lib/Driver/Driver.cpp lib/Driver/ToolChain.cpp lib/Driver/ToolChains.cpp lib/Driver/ToolChains.h lib/Driver/WindowsToolChain.cpp test/Driver/prefixed-tools.c test/Driver/pref

[Chandler Carruth]

On Tue, Jan 31, 2012 at 9:57 AM, Sebastian Pop <spop at codeaurora.org> wrote:

> On Tue, Jan 31, 2012 at 6:08 AM, James Molloy <james.molloy at arm.com>
> wrote:
> > Hi,
> >
> >> If you are doing cross-compiling and you
> >> can't get the compiler name right, you have bigger issues. I still
> >> maintain that auto-detection like that is not only unreliable, it makes
> >> it a lot harder to find issues when (not if) they happen.
> >
> > FWIW, I completely agree with this subpoint. It's something the target
> > database hopes to do - remove magic. I'm not sure what Chandler's
> end-game
> > plan is though, hopefully the same :/
>
> I also agree with this point: there are toolchains that clang will never
> be able
> to guess in an automatic way.


I actually agree on this too. ;]


> I would like clang to rely less on the current
> automagic detection and more on what the user is asking,


And here is where I think the confusion arises.

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.

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.

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).

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20120131/84a699b0/attachment.html>