The first problem to fix is to stop creating synthetic *Table_gen
targets next to all of the LLVM libraries. These had no real effect as
CMake specifies that add_custom_command(OUTPUT ...) directives (what the
'tablegen(...)' stuff expands to) are implicitly added as dependencies
to all the rules in that CMakeLists.txt.

These synthetic rules started to cause problems as we started more and
more heavily using tablegen files from *subdirectories* of the one where
they were generated. Within those directories, the set of tablegen
outputs was still available and so these synthetic rules added them as
dependencies of those subdirectories. However, they were no longer
properly associated with the custom command to generate them. Most of
the time this "just worked" because something would get to the parent
directory first, and run tablegen there. Once run, the files existed and
the build proceeded happily. However, as more and more subdirectories
have started using this, the probability of this failing to happen has
increased. Recently with the MC refactorings, it became quite common for
me when touching a large enough number of targets.

To add insult to injury, several of the backends *tried* to fix this by
adding explicit dependencies back to the parent directory's tablegen
rules, but those dependencies didn't work as expected -- they weren't
forming a linear chain, they were adding another thread in the race.

This patch removes these synthetic rules completely, and adds a much
simpler function to declare explicitly that a collection of tablegen'ed
files are referenced by other libraries. From that, we can add explicit
dependencies from the smaller libraries (such as every architectures
Desc library) on this and correctly form a linear sequence. All of the
backends are updated to use it, sometimes replacing the existing attempt
at adding a dependency, sometimes adding a previously missing dependency
edge.

Please let me know if this causes any problems, but it fixes a rather
persistent and problematic source of build flakiness on our end.

llvm-svn: 136023

header search path.

llvm-svn: 135952

tablegenning to all libraries and executables.

llvm-svn: 135908

under cmake).

Add libprofile_rt.a so that we can tell clang to link against it in --coverage
mode. Also turn it on by default in cmake builds.

Oscar, this touches a change you made for EXCLUDE_FROM_ALL support -- I think
I've done the right thing, but please let me know (or fix and commit) if not!

llvm-svn: 130470

llvm-svn: 130199

scheme is used by the functionality related to find_package.

llvm-svn: 128889

unnecesary conditionals and introduced a new convenience function.

The problem was that the list of libraries for Clang's unit tests was
<clang libraries> <system libraries> <llvm libraries>. As the llvm
libraries references symbols defined on the system libraries, those
were reported as undefined.

llvm-svn: 128484

Tested that MinGW/MSYS builds fine without that.

llvm-svn: 128033

link command.

Fixed a pair of IF expressions too.

llvm-svn: 127546

llvm-svn: 126224

Requires CMake 2.8.3 or newer.

llvm-svn: 126092

of testing for its presence at cmake time.

This way the build automatically regenerates the makefiles when a svn
update brings in a new sublibrary.

llvm-svn: 126068

llvm-svn: 125968

Patch by Wesley Peck!

llvm-svn: 122395

cmake/modules/AddLLVM.cmake: Add empty "phony" target in add_llvm_loadable_module() even if loadable module were not supported.

llvm-svn: 121455

llvm-svn: 117130

PR 8375

llvm-svn: 116479

available targets unless LLVM_INCLUDE_X is ON. LLVM_BUILD_X implies
LLVM_INCLUDE_X"

It breaks the configuration phase when cmake is invoked without
parameters, it is too complex for the purpose and introduces an
incovenience for the user (as both LLVM_BUILD_X and LLVM_INCLUDE_X
must set to OFF for not including X on the build)

llvm-svn: 114795

unless LLVM_INCLUDE_X is ON. LLVM_BUILD_X implies LLVM_INCLUDE_X

llvm-svn: 114747

This reverts commit r113632

Conflicts:

	cmake/modules/AddLLVM.cmake

llvm-svn: 113819

llvm-svn: 113676

llvm-svn: 113632

llvm-svn: 89636

LLVM_BUILD_TOOLS or LLVM_BUILD_EXAMPLES are OFF.

llvm-svn: 89635

llvm-svn: 86684

llvm-svn: 86656

llvm-svn: 79186

failure with VS 9.0, nmake and cmake 2.6.4. The buildbot output does
not show the patch level of cmake, it just says 2.6.

Sadly, parallel builds are broken due to recent changes on LLVM Target
libraries and its auxiliaries (TargetInfo, AsmPrinter, AsmParser). I
have a patch for stablishing the correct dependencies, but cmake is
buggy and generates makefiles that can't handle them.

llvm-svn: 79180

parallel builds.

llvm-svn: 79177

llvm-svn: 79144

way we ensure that tablegenned files exist before they are #include'd
by the LLVM Target sublibraries. Required for parallel builds.

llvm-svn: 78996

llvm-svn: 78990

libraries for an executable.

Now LLVMConfig uses a new system for sorting library dependencies, as
the list of dependent libraries for each entry of FinalLibDeps.txt no
longer is topologically sorted.

llvm-svn: 78787

llvm-svn: 74003

llvm-svn: 73979

llvm-svn: 73970

cleans up the CMake-based build system a bit. Started by a patch from
Xerxes Rånby.

llvm-svn: 73969

Patch by Ingmar Vanhassel!

llvm-svn: 73216

the CMake-generated Xcode project build properly.

llvm-svn: 72883

used by CMake with --ldflags.

llvm-svn: 72470