Commit Graph

849 Commits

Author SHA1 Message Date
David Blaikie 74d8806635 Revert "Enable -Wdeprecated in the cmake build now that LLVM (& Clang, Polly, and LLD) are -Wdeprecated clean"
This reverts commit r248963.

Seems there's some standard libraries (and libcxxabi implementations)
that aren't -Wdeprecated clean... hrm.

llvm-svn: 248972
2015-10-01 00:44:21 +00:00
David Blaikie 3830d68bc1 Enable -Wdeprecated in the cmake build now that LLVM (& Clang, Polly, and LLD) are -Wdeprecated clean
This particularly helps enforce the C++ Rule of 5 (for new move ops this
is already an error, but for a type only using C++98 features (copy
ctor/assign, dtor) it is only deprecated, not invalid)

Applying the flag for any GCC compatible compiler - GCC doesn't warn on
the Rule of 5 cases that C++11 deprecates, but it doesn't have other
false positives so far as I could see (compiling with GCC 4.8 didn't
produce any -Wdeprecated warnings I could spot).

Reviewers: aaron.ballman

Differential Revision: http://reviews.llvm.org/D13314

llvm-svn: 248963
2015-09-30 23:36:12 +00:00
John Brawn c11ef2a89c [CMake] Make the bindir and libdir arguments to set_output_directory optional
When building a plugin against an installed LLVM toolchain using
add_llvm_loadable_module (in the documented manner) doesn't work as nothing sets
the *_OUTPUT_INTDIR variables causing an error when set_output_directory is
called. Making those arguments optional (causing the default output directory
to be used) fixes this.

Differential Revision: http://reviews.llvm.org/D13215

llvm-svn: 248911
2015-09-30 15:20:51 +00:00
John Brawn 8a3ec2aec2 [CMake] Adjust the variables set by LLVMConfig.cmake
When using LLVMConfig.cmake from an installed toolchain in order to build a
loadable pass using add_llvm_loadable_module LLVM_ENABLE_PLUGINS and
LLVM_PLUGIN_EXT must be set. Also make LLVM_DEFINITIONS be set to what it
actually is.

Differential Revision: http://reviews.llvm.org/D13214

llvm-svn: 248884
2015-09-30 10:34:06 +00:00
John Brawn c23801d311 [CMake] Move the setting of LLVM_COMPILER_IS_GCC_COMPATIBLE to a separate file
Currently LLVM_COMPILER_IS_GCC_COMPATIBLE is set as a side-effect of determining
the stdlib to use in HandleLLVMStdlib, which causes problems when attempting to
use AddLLVM from an installed LLVM toolchain, as HandleLLVMStdlib is not used.
Move the setting of this variable into DetermineGCCCompatible and include that
from both AddLLVM and HandleLLVMStdlib.

Differential Revision: http://reviews.llvm.org/D13216

llvm-svn: 248798
2015-09-29 14:33:58 +00:00
Chris Bieneman 895d96a919 [CMake] Adding ALWAYS_GENERATE option to symlink utility functions.
This implements the behavior required for clang symlinks which should be always generated.

llvm-svn: 248039
2015-09-18 21:08:32 +00:00
Chris Bieneman 08249706cd [CMake] More cleanup of installing symlinks.
In order to support building clang out-of-tree the install_symlink script needs to be installed, and it needs to be found by searching the CMAKE_MODULE_PATH.

This change renames install_symlink -> LLVMInstallSymlink so it doesn't conflict with naming from other projects, and adds searching behavior in AddLLVM.cmake

llvm-svn: 248009
2015-09-18 17:39:58 +00:00
Chris Bieneman bff03b0982 [CMake] More refactoring of symlink creation.
This refactoring is to enable clang to re-use this code.

llvm-svn: 247850
2015-09-16 20:49:59 +00:00
Chris Bieneman bde7e4563e [CMake] Rename target->dest as per feedback from Chapuni on http://reviews.llvm.org/D12864
llvm-svn: 247658
2015-09-15 02:15:53 +00:00
Chris Bieneman 6d43afc7bd [CMake] Refactor and cleanup generating and installing symlinks to tools.
Summary: This change generalizes symlink generation and makes symlinks to tools obey LLVM_TOOLCHAIN_TOOLS. It makes it so that if you exclude llvm-ar from LLVM_TOOLCHAIN_TOOLS you don't end up with broken symlinks to llvm-lib and llvm-ranlib in your install.

Reviewers: bogner, chapuni, rafael

Subscribers: llvm-commits

Differential Revision: http://reviews.llvm.org/D12864

llvm-svn: 247632
2015-09-14 23:09:06 +00:00
Jordan Rose 85a22f8b6d [CMake] s/LLVM_SOURCE_DIR/LLVM_MAIN_SRC_DIR/
Fix-up for r247305 to use the right variable. There's another use of
LLVM_SOURCE_DIR in this file that is probably also questionable, but it's
for Windows so I'm going to leave it alone.

llvm-svn: 247311
2015-09-10 17:55:02 +00:00
Chris Bieneman 170fd9cb6e [CMake] Allow LLVM_TOOLCHAIN_TOOLS to be overridden
llvm-svn: 247306
2015-09-10 17:23:32 +00:00
Jordan Rose 3d75297056 [CMake] Fix Xcode build with LLVM_ENABLE_OBJLIB.
This amends chapuni's r246156 to handle an Xcode quirk, one even called out
in the CMake documentation:

    Some native build systems may not like targets that have only object files,
    so consider adding at least one real source file to any target that
    references $<TARGET_OBJECTS:objlib>.

I've limited the scope of this hack to Xcode for now.

llvm-svn: 247305
2015-09-10 17:18:51 +00:00
Aaron Ballman e11ce62707 Silencing C4141 warnings that were introduced en masse because __forceinline cannot be combined with inline in MSVC without triggering this diagnostic. This is safe to disable because clang will catch instances of the issue with -Wduplicate-decl-specifier, so we are not losing diagnostic coverage.
llvm-svn: 247275
2015-09-10 12:53:40 +00:00
Joseph Tremoulet e5e75afe8f [CMake] Flag recursive cmake invocations for cross-compile
Summary:
Cross-compilation uses recursive cmake invocations to build native host
tools.  These recursive invocations only forward a fixed set of
variables/options, since the native environment is generally the default.
This change adds -DLLVM_TARGET_IS_CROSSCOMPILE_HOST=TRUE to the recursive
cmake invocations, so that cmake files can distinguish these recursive
invocations from top-level ones, which can explain why expected options
are unset.

LLILC will use this to avoid trying to generate its build rules in the
crosscompile native host target (where it is not needed), which would fail
if attempted because LLILC requires a cmake variable passed on the command
line, which is not forwarded in the recursive invocation.

Reviewers: rnk, beanz

Subscribers: llvm-commits

Differential Revision: http://reviews.llvm.org/D12679

llvm-svn: 247151
2015-09-09 14:57:06 +00:00
NAKAMURA Takumi bb7483dd77 [CMake][CMP0051] Avoid for user of objlib to use llvm_update_compile_flags().
$<TARGET_OBJECTS> shouldn't require compile flags. Flags are set in obj.${name}.

llvm-svn: 246984
2015-09-08 07:42:06 +00:00
Andrew Wilkins bb6d95fc3a [cmake] rework LLVM_LINK_LLVM_DYLIB option handling
Summary:
This diff attempts to address the concerns raised in
http://reviews.llvm.org/D12488.

We introduce a new USE_SHARED option to llvm_config,
which, if set, causes the target to be linked against
libLLVM.

add_llvm_utility now uniformly disables linking against
libLLVM. These utilities are not intended for distribution,
and this keeps the option handling more centralised.

llvm-shlib is now processes before any other "tools"
subdirectories, ensuring the libLLVM target is defined
before its dependents.

One main difference from what was requested: llvm_config
does not prune LLVM_DYLIB_COMPONENTS from the components
passed into explicit_llvm_config. This is because the "all"
component does something special, adding additional
libraries (namely libLTO). Adding the component libraries
after libLLVM should not be a problem, as symbols will be
resolved in libLLVM first.

Finally, I'm not really happy with the
DISABLE_LLVM_LINK_LLVM option, but I'm not sure of a
better way to get the following:
 - link all tools and shared libraries to libLLVM if
   LLVM_LINK_LLVM_DYLIB is set
 - some way of explicitly *not* doing so for utilities
   and libLLVM itself
Suggestions for improvement here are particularly welcome.

Reviewers: beanz

Subscribers: llvm-commits

Differential Revision: http://reviews.llvm.org/D12590

llvm-svn: 246918
2015-09-05 08:27:33 +00:00
NAKAMURA Takumi d4b21935cc [CMake] Don't use OBJLIB on Xcode.
I got a few reports it didn't work.

llvm-svn: 246629
2015-09-02 10:11:26 +00:00
Justin Bogner 1ded69870e cmake: Error instead of warning and dropping invalid LLVM_USE_SANITIZER
Currently, if you call cmake with a typo in an LLVM_USE_SANITIZER
value, there's a cmake warning and the build goes on with no
sanitizers at all. This isn't a good behaviour, since cmake warnings
are fairly easy to miss and the resulting behaviour is that it looks
like the build is sanitizer clean.

Upgrade these warnings to errors so misconfigurations are more
obvious.

llvm-svn: 246531
2015-09-01 05:45:07 +00:00
Andrew Wilkins 9211396d82 Enable linking tools, shared libraries against libLLVM
Summary:
Three closely related changes, to have a mode in which we link all
executables and shared libraries against libLLVM. 

1. Add a new LLVM_LINK_LLVM_DYLIB cmake option, which, when ON, will link
   executables and shared libraries against libLLVM. For this to work, it
   is necessary to also set LLVM_BUILD_LLVM_DYLIB and LLVM_DYLIB_EXPORT_ALL.

   It is not strictly necessary to set LLVM_DISABLE_LLVM_DYLIB_ATEXIT, but
   we also default to OFF in this mode, or tools tend to misbehave (e.g.
   stdout may not flush on exit when output is buffered.)

   llvm-config and Tablegen do not use libLLVM, as they are dependencies of
   libLLVM.

2. Modify llvm-go to take a new flag, "linkmode=component-libs|dylib".
   Depending on which one is passed (default is component-libs), we link
   with the individual libraries or libLLVM respectively. We pass in dylib
   when LLVM_LINK_LLVM_DYLIB is ON.

3. Fix LLVM_DYLIB_EXPORT_ALL on Linux, and expand the symbols exported to
   actually export all. Don't strip leading underscore from symbols on Linux,
   and make sure we get all exported symbols and weak-with-default symbols
   ("W" in nm output). Without these changes, passes won't load because
   the "Annotate..." symbols defined in lib/Support/Valigrind.cpp are not
   found.

Testing:
 - Ran default build ("ninja") with LLVM, clang, compiler-rt, llgo, lldb.
 - Ran "check", "check-clang", "check-tsan", "check-libgo" targets. I've
   never had much success with LLDB tests, and llgoi is currently broken
   so check-llgo fails for an unrelated reason.
 - Ran "lldb" to ensure it loads.

Reviewers: chandlerc, beanz, pcc, rnk

Subscribers: rnk, chapuni, sylvestre.ledru, llvm-commits

Differential Revision: http://reviews.llvm.org/D12488

llvm-svn: 246527
2015-09-01 03:14:31 +00:00
NAKAMURA Takumi b5288ba9d1 [CMake] Fix build on MSVC in r246156.
add_windows_version_resource_file() affects ALL_FILES. OBJLIB shouldn't have *.obj as SOURCES.

llvm-svn: 246241
2015-08-28 00:36:58 +00:00
NAKAMURA Takumi e6bc093b42 [CMake] OBJLIB-ize *-tblgen.
This improves dependency chain of;

  (LLVMSupport && LLVMTableGen) && (*.cpp in *-tblgen) && (linking *-tblgen)

with;

  (LLVMSupport && LLVMTableGen && *.cpp) && (linking *-tblgen)

llvm-svn: 246156
2015-08-27 16:10:47 +00:00
Reid Kleckner 38b8938f40 [cmake] Pass /manifest:no to the linker when asan is enabled
This is a workaround for PR24476.

llvm-svn: 245945
2015-08-25 16:06:40 +00:00
NAKAMURA Takumi 6fa8532041 [CMake] add_llvm_external_project: Just warn about nonexistent directories.
These entries were generated accidentally.

llvm-svn: 245783
2015-08-22 05:11:02 +00:00
NAKAMURA Takumi 04e2da526f [CMake] Make LLVM_EXTERNAL_*_SOURCE_DIR consistent against older buildsites.
If corresponding in-tree subdirectory exists, just ignore LLVM_EXTERNAL* stuff.
Otherwise, set LLVM_TOOL_*_BUILD ON/OFF properly according to LLVM_EXTERNAL_*.

This makes easier to walk among old revisions *without* deleteing CMakeCache.txt.

Before r242059, LLVM_EXTERNAL_* was working like;

  if(EXISTS ${*_SOURCE_DIR}/CMakeLists.txt)
    set(*_BUILD ON CACHE)
    if(*_BUILD is ON)
      add_subdirectory(*_SOURCE_DIR)
    endif()
  endif()

llvm-svn: 245782
2015-08-22 04:53:52 +00:00
Dan Liew 1e3dc527ea Filter libraries that are not installed out of CMake exports (currently
gtest and gtest_main) when generating ``Makefile.llvmbuild``.

Libraries that are not installed should not be exported because they
won't be available from an install tree.  Rather than filtering out the
gtest libraries in cmake/modules/Makefile, simply teach llvm-build to
filter out libraries that will not be installed from its generated list
of exported libraries.

Note that LLVMBUILD_LIB_DEPS_* are used during our own CMake build
process so we cannot filter LLVMBUILD_LIB_DEPS_gtest* out in llvm-build.
We must leave this gtest filter logic in cmake/modules/Makefile.

llvm-svn: 245718
2015-08-21 18:10:57 +00:00
Dan Liew ef1fa56c83 llvm-build: Adopt generation of LLVM_LIBS_TO_EXPORT. Patch by
Brad King.

Move `LLVM_LIBS_TO_EXPORT` over to Makefile.llvmbuild and generate it
from `llvm-build` using the same logic used to export the dependencies
of these libraries.  This avoids depending on `llvm-config`.

This refactoring was originally motivated by issue  due to commit
r243297 (Fix `llvm-config` to emit the linker flag for the combined
shared object, 2015-07-27) changing the output of `llvm-config --libs`
to not have the individual libraries when we configure with
`--enable-shared`.  That change was reverted by r244108 but this
refactoring makes sense on its own anyway.

llvm-svn: 245717
2015-08-21 18:10:55 +00:00
Yaron Keren 528d8d6092 Disable Visual C++ 2013 Debug mode assert on null pointer in some STL algorithms,
such as std::equal on the third argument. This reverts previous workarounds.

Predefining _DEBUG_POINTER_IMPL disables Visual C++ 2013 headers from defining
it to a function performing the null pointer check. In practice, it's not that
bad since any function actually using the nullptr will seg fault. The other
iterator sanity checks remain enabled in the headers.

Reviewed by Aaron Ballmanþ and Duncan P. N. Exon Smith.

llvm-svn: 245711
2015-08-21 17:31:03 +00:00
Reid Kleckner d7a568fc4f [cmake] Start adding support for LLVM_USE_SANITIZER=Address on Windows
Pass "-fsanitize=address" to the compiler and "-debug" to the linker.

llvm-svn: 245070
2015-08-14 16:48:34 +00:00
Rafael Espindola f846557eb8 Use /Zc:inline when building with MSVC.
This reduces the total .obj size when building llvm from
496,690,342 to 219,334,936 bytes.

llvm-svn: 244767
2015-08-12 17:09:25 +00:00
Reid Kleckner 7752db61cc Revert "[cmake] Add helper for finding potentially external projects"
This reverts commit r244633.

We aren't going to be able to use it because the compiler-rt build can
be built standalone without an LLVM source dir *or* an installed copy of
LLVM.

llvm-svn: 244648
2015-08-11 19:02:57 +00:00
Reid Kleckner de98228fab [cmake] Add helper for finding potentially external projects
I plan to use this from compiler-rt, but it's useful for any LLVM
project that depends on more than just LLVM.

llvm-svn: 244633
2015-08-11 17:16:35 +00:00
Justin Bogner c7e3f3ab6e Remove the configure and cmake checks for sys/wait.h
If we don't have sys/wait.h and we're on a unix system there's no way
that several of the llvm tools work at all. This includes clang.

Just remove the configure and cmake checks entirely - we'll get a
build error instead of building something broken now.

llvm-svn: 243957
2015-08-04 06:29:58 +00:00
Douglas Katzman 280ee917d7 Use a specified list of languages in cmake project() command.
This allows asm files and Cxx files to be compiled with different flags
rather than treating them identically. LLVM itself has no asm files
other than tests, but this setting is inherited by the compiler-rt
project (unless compiled standalone), which does have asm files.

Differential Revision: http://reviews.llvm.org/D10707

llvm-svn: 243419
2015-07-28 14:43:53 +00:00
Saleem Abdulrasool f95da49f25 build: fix small typo in cmake doxygen build
A search word spelled as "searhc" in the LLVM_DOXYGEN_SEARCHENGINE_URL cmake
variable docstring.

Patch by Daniel Otero!

llvm-svn: 243082
2015-07-24 01:14:25 +00:00
Yaron Keren 5519ad3368 Avoid using -Wl,-z,defs on Cygwin.
Prior to CMAKE 2.8.4 that was covered by the WIN32 conditional but
from 2.8.4 CMAKE no longer defined WIN32 when running under Cygwin
and it needs its own test.

Patch by Martell Malone!

http://reviews.llvm.org/D11347

llvm-svn: 242993
2015-07-23 08:06:12 +00:00
Chris Bieneman 19d42692e7 [CMake] Projects supported via LLVM_EXTERNAL_*_SOURCE_DIR need to be explicitly specified.
One part of my refactoring from r242705 is untenable due to how CMake caches variables. There is no way other than caching to allow variables to be set in one directory and globally readable, but we really don't want to cache the temporary value marking that a directory has already been included.

llvm-svn: 242793
2015-07-21 15:53:09 +00:00
Andrew Wilkins 6c1bfa93f5 [cmake] pass GO_EXECUTABLE to llgo-go
Summary:
When calling llgo-go from the llvm_add_go_executable
cmake function, specify $GO_EXECUTABLE as the go
command to call. Without this, llgo-go searches $PATH
which may be inconsistent with $GO_EXECUTABLE.

Reviewers: pcc

Subscribers: llvm-commits

Differential Revision: http://reviews.llvm.org/D11290

llvm-svn: 242749
2015-07-21 00:46:23 +00:00
Chris Bieneman 077f3fe1a1 [CMake] Fixing inconsistency caused by copy-pasta.
This will actually fix the PR 24194.

llvm-svn: 242748
2015-07-21 00:44:47 +00:00
Chris Bieneman 95ba62c91a [CMake] Fixing a problem with external projects that aren't getting enabled properly.
This should address PR 24194, and some builedbot failures.

llvm-svn: 242746
2015-07-21 00:39:53 +00:00
Aaron Ballman 0cba642a05 Suppress two warnings from MSVC 2015 that are triggered under /W4. Since we turn off exceptions in the code base, C4577 is moot. C4091 triggers on system headers and is a benign construct.
llvm-svn: 242708
2015-07-20 21:14:14 +00:00
Chris Bieneman 580d8159d5 [CMake] Cleanup tools/CMakeLists.txt to take advantage of the auto-registration that was already partially working.
Re-landing r242059 which re-landed r241621... I'm really bad at this.

Summary (r242059):
This change re-lands r241621, with an additional fix that was required to allow tool sources to live outside the llvm checkout. It also no longer renames LLVM_EXTERNAL_*_SOURCE_DIR. This change was reverted in r241663, because it renamed several variables of the format LLVM_EXTERNAL_*_* to LLVM_TOOL_*_*.

Summary (r241621):
The tools CMakeLists file already had implicit tool registration, but there were a few things off about it that needed to be altered to make it work. This change addresses all that. The changes in this patch are:

* factored out canonicalizing tool names from paths to CMake variables * removed the LLVM_IMPLICIT_PROJECT_IGNORE mechanism in favor of LLVM_EXTERNAL_${nameUPPER}_BUILD which I renamed to LLVM_TOOL_${nameUPPER}_BUILD because it applies to internal and external tools
* removed ignore_llvm_tool_subdirectory() in favor of just setting LLVM_TOOL_${nameUPPER}_BUILD to Off
* Added create_llvm_tool_options() to resolve a bug in add_llvm_external_project() - the old LLVM_EXTERNAL_${nameUPPER}_BUILD would not work on a clean CMake directory because the option could be created after it was set in code.
* Removed all but the minimum required calls to add_llvm_external_project from tools/CMakeLists.txt

Differential Revision: http://reviews.llvm.org/D10665

llvm-svn: 242705
2015-07-20 20:36:06 +00:00
NAKAMURA Takumi ae5d78d722 [CMake] Unbreak add_llvm_external_project when external projects are specified.
LLVM_EXTERNAL_*_SOURCE_DIR is reset as PATH with set(CACHE PATH).
Then the CACHE PATH variable, LLVM_EXTERNAL_*_SOURCE_DIR, is normalized as
${CMAKE_SOURCE_DIR}/${path_var} if ${path_var} is relative.

llvm-svn: 242120
2015-07-14 05:12:53 +00:00
Chris Bieneman d36f614e20 [CMake] Forgot to quote the first part of STREQUAL.
llvm-svn: 242103
2015-07-14 01:19:07 +00:00
Chris Bieneman 3da1b6e260 [CMake] We shouldn't be storing values in the cache unless they actually need CMake cache behavior.
add_llvm_external_project puts LLVM_EXTERNAL_${nameUPPER}_SOURCE_DIR into the cache even if it is just the in-tree default path. This causes all sorts of oddness, and makes it so that I can't change the behavior of this variable.

This patch never puts LLVM_EXTERNAL_${nameUPPER}_SOURCE_DIR into the cache. It will only end up in the cache if it is specified on the command line, which is the correct behavior.

There is also a temporary change to remove non-default values from the cache if they are already present. This should have the impact of cleaning out unncecissary values from the caches on the buildbots and people's local build directories. This part of the change is marked with a TODO and can be removed in a few days.

llvm-svn: 242102
2015-07-14 01:17:43 +00:00
Chris Bieneman 86b1fd77e6 Revert "[CMake] Cleanup tools/CMakeLists.txt to take advantage of the auto-registration that was already partially working."
Reverting r242059 because it broke some bots. I'm attempting to reproduce the failures now.

llvm-svn: 242060
2015-07-13 20:30:58 +00:00
Chris Bieneman 8ac6d119b7 [CMake] Cleanup tools/CMakeLists.txt to take advantage of the auto-registration that was already partially working.
Summary:
This change re-lands r241621, with an additional fix that was required to allow tool sources to live outside the llvm checkout. It also no longer renames LLVM_EXTERNAL_*_SOURCE_DIR. This change was reverted in r241663, because it renamed several variables of the format LLVM_EXTERNAL_*_* to LLVM_TOOL_*_*.

Original Summary:
The tools CMakeLists file already had implicit tool registration, but there were a few things off about it that needed to be altered to make it work. This change addresses all that. The changes in this patch are:

* factored out canonicalizing tool names from paths to CMake variables * removed the LLVM_IMPLICIT_PROJECT_IGNORE mechanism in favor of LLVM_EXTERNAL_${nameUPPER}_BUILD which I renamed to LLVM_TOOL_${nameUPPER}_BUILD because it applies to internal and external tools
* removed ignore_llvm_tool_subdirectory() in favor of just setting LLVM_TOOL_${nameUPPER}_BUILD to Off
* Added create_llvm_tool_options() to resolve a bug in add_llvm_external_project() - the old LLVM_EXTERNAL_${nameUPPER}_BUILD would not work on a clean CMake directory because the option could be created after it was set in code.
* Removed all but the minimum required calls to add_llvm_external_project from tools/CMakeLists.txt

Differential Revision: http://reviews.llvm.org/D10665

llvm-svn: 242059
2015-07-13 20:23:15 +00:00
NAKAMURA Takumi 58843eede5 Revert r241621, "[CMake] Cleanup tools/CMakeLists.txt to take advantage of the auto-registration that was already partially working."
It broke the build that relies on LLVM_EXTERNAL_CLANG_*.

llvm-svn: 241663
2015-07-08 02:35:43 +00:00
Chris Bieneman 3765588f65 [CMake] Cleanup tools/CMakeLists.txt to take advantage of the auto-registration that was already partially working.
Summary:
The tools CMakeLists file already had implicit tool registration, but there were a few things off about it that needed to be altered to make it work. This change addresses all that. The changes in this patch are:

* factored out canonicalizing tool names from paths to CMake variables
* removed the LLVM_IMPLICIT_PROJECT_IGNORE mechanism in favor of LLVM_EXTERNAL_${nameUPPER}_BUILD which I renamed to LLVM_TOOL_${nameUPPER}_BUILD because it applies to internal and external tools
* removed ignore_llvm_tool_subdirectory() in favor of just setting LLVM_TOOL_${nameUPPER}_BUILD to Off
* Added create_llvm_tool_options() to resolve a bug in add_llvm_external_project() - the old LLVM_EXTERNAL_${nameUPPER}_BUILD would not work on a clean CMake directory because the option could be created after it was set in code.
* Removed all but the minimum required calls to add_llvm_external_project from tools/CMakeLists.txt

Reviewers: bogner, samsonov, chapuni, beanz

Subscribers: llvm-commits

Differential Revision: http://reviews.llvm.org/D10665

llvm-svn: 241621
2015-07-07 20:24:55 +00:00
NAKAMURA Takumi 3eb06667bd [CMake] add_llvm_symbol_exports: Use Python oneliner instead of "cmd.exe /c type" to generate *.def.
llvm-svn: 241402
2015-07-05 08:56:38 +00:00