Classes in Tools.h inherit ultimately from Tool, which is a noun,
but subclasses of Tool were named for their operation, such as "Compile",
wherein the constructor call "Compile(args...)" could be misconstrued
as actually causing a compile to happen.
Likewise various other methods were not harmonious with their effect,
in that "BuildLinker()" returned a "new namespace::Link(...)"
instead of a "new namespace::Linker(...)" which it now does.
Exceptions: Clang and ClangAs are un-renamed. Those are their rightful names.
And there is no particulary great way to name the "Lipo-er" and a few others.
Differential Revision: http://reviews.llvm.org/D10595
llvm-svn: 240455
It reverts commits as follows:
r211866: "Driver: use GNU::Link for the Generic_GCC toolchain"
r211895: "Replace GetProgramPath("ld") with GetLinkerPath()."
r211995: "Driver: add a cygwin linker tool"
llvm-svn: 211998
This changes the behaviour of the driver for linking to match that of the
Generic_GCC::Assemble. The default link should use "ld" rather than "gcc" for
the linker as gcc does. This avoids the unnecessary round-tripping through gcc.
It also is much more reasonable behaviour from the user's perspective. This
should have been updated with SVN r195554 which changed the behaviour of
Generic_GCC::Assemble.
The gcc_forward test needs to be updated to mark the fact that -march is a flag
for GCC not ld. This was updated as a typo fix, but added a check for a flag
that is not a link flag.
The bindings test covers the change for testing, and thus no new test was added.
llvm-svn: 211866
The integrated assembler was already the default for win32. It is now able
to handle a clang bootstrap on mingw, so make it the default.
llvm-svn: 195676
Clang knows how to use the gnu assembler directly from doing so on linux and
hurd. The existing support worked out of the box on cygwin and mingw and I was
able to bootstrap clang with it in both systems (with pending patches for the
new mingw abi, but that is independent of the assembler).
llvm-svn: 195554
we had the -ccc-clang-cxx and -ccc-no-clang-cxx options to force them
on or off for testing.
Clang c++ support is now production quality and these options are dead.
llvm-svn: 166986
clang itself. This dates back to clang's early days and while it looks like
some of it is still used (for kext for example), other parts are probably dead.
Remove the -ccc-clang-archs option and associated code. I don't think there
is any remaining setup where clang doesn't support an architecture but it can
expect an working gcc cross compiler to be available.
A nice side effect is that tests no longer need to differentiate architectures
that are included in production builds of clang and those that are not.
llvm-svn: 165545
regardless of the architecture).
- This is a good default for development & testing; for example without this
any tests using 'clang' in the test suite will fail on PowerPC, since the
driver will avoid using clang.
- We don't want to actually ship something built this way, but that should be
handled via some sort of configuration file.
llvm-svn: 76886
- Don't default to using clang for C++ (use -ccc-clang-cxx to
override).
- Default to only using clang on i386 and x86_64 (use
-ccc-clang-archs "" to override).
- <rdar://problem/6712350> [driver] clang should not be used on
powerpc by default
- <rdar://problem/6705767> driver should default to -ccc-no-clang-cxx
I plan to add a warning that we are not using the clang compiler for
the given compilation so that users do not think clang is being used
in situations it isn't.
This change is motivated by the desire to be able to drop clang into a
build and have things "just work", even if it happens to get used to
compile C++ code or code for an architecture we don't support yet.
llvm-svn: 67640
Douglas Katzman