llvm-svn: 160850

express library-level dependencies within Clang.

This is no more verbose really, and plays nicer with the rest of the
CMake facilities. It should also have no change in functionality.

llvm-svn: 158888

Zap the /Za compiler switch from MSVC projects, the option is considered harmful even by Microsoft people and clang won't build using the MSVC 2012 RC if not removed.

Only 1 minor code change was necessary: can't use cdecl as variable name anymore.

llvm-svn: 158063

llvm-svn: 157933

Really just a wild stab in the dark.

llvm-svn: 155974

Unify Options.td and CC1Options.td, in a first step towards unifying the serialization logic in Frontend and Driver.

Reviewed by Eric, Doug and Chandler, and here: http://llvm.org/reviews/r/7/

llvm-svn: 155916

did anything. The two big pieces of functionality it tried to provide
was to cache the ToolChain objects for each target, and to figure out
the exact target based on the flag set coming in to an invocation.
However, it had a lot of flaws even with those goals:
 - Neither of these have anything to do with the host, or its info.
 - The HostInfo class was setup as a full blown class *hierarchy* with
   a separate implementation for each "host" OS. This required
   dispatching just to create the objects in the first place.
 - The hierarchy claimed to represent the host, when in fact it was
   based on the target OS.
 - Each leaf in the hierarchy was responsible for implementing the flag
   processing and caching, resulting in a *lot* of copy-paste code and
   quite a few bugs.
 - The caching was consistently done based on architecture alone, even
   though *any* aspect of the targeted triple might change the behavior
   of the configured toolchain.
 - Flag processing was already being done in the Driver proper,
   separating the flag handling even more than it already is.

Instead of this, we can simply have the dispatch logic in the Driver
which previously created a HostInfo object create the ToolChain objects.
Adding caching in the Driver layer is a tiny amount of code. Finally,
pulling the flag processing into the Driver puts it where it belongs and
consolidates it in one location.

The result is that two functions, and maybe 100 lines of new code
replace over 10 classes and 800 lines of code. Woot.

This also paves the way to introduce more detailed ToolChain objects for
various OSes without threading through a new HostInfo type as well, and
the accompanying boiler plate. That, of course, was the yak I started to
shave that began this entire refactoring escapade. Wheee!

llvm-svn: 148950

especially nice as the Windows toolchain needs the windows header files,
and has lots of platform specific hooks in it.

To facilitate the split, hoist a bunch of file-level static helpers into
class-level static helpers. Spiff up their doxygen comments while there
as they're now more likely to be looked up via docs.

Hopefully, this will be followed by further breaking apart of the
toolchain definitions. Most of the large and complex ones should likely
live on their own. I'm looking at you Darwin. ;]

llvm-svn: 146840

llvm-svn: 143770

llvm-svn: 125275

This reverts commit r113631

Conflicts:

	CMakeLists.txt
	lib/CodeGen/CMakeLists.txt

llvm-svn: 113817

of whatever we were using before...

llvm-svn: 113631

llvm-svn: 113489

llvm-svn: 106188

Driver/MC: Add 'clang -cc1as' integrated assembler tool, currently accepts approximately the same interface as 'llvm-mc'.

llvm-svn: 104239

llvm-svn: 99191

llvm-svn: 89332

llvm-svn: 89330

llvm-svn: 89288

llvm-svn: 89283

llvm-svn: 73976

llvm-svn: 73700

llvm-svn: 67633

llvm-svn: 66884

driver taking lib/Driver.

llvm-svn: 65811

llvm-svn: 60269

llvm-svn: 58716

must be under the `tools' subdirectory of the LLVM *source* tree.

llvm-svn: 58180