summaryrefslogtreecommitdiffstats
path: root/llvm/cmake/modules
Commit message (Collapse)AuthorAgeFilesLines
...
* Enable -Wdeprecated in the cmake build now that LLVM (& Clang, Polly, and ↵David Blaikie2015-09-301-1/+1
| | | | | | | | | | | | | | | | | | | 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
* [CMake] Make the bindir and libdir arguments to set_output_directory optionalJohn Brawn2015-09-301-20/+29
| | | | | | | | | | | | 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
* [CMake] Adjust the variables set by LLVMConfig.cmakeJohn Brawn2015-09-301-1/+4
| | | | | | | | | | | 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
* [CMake] Move the setting of LLVM_COMPILER_IS_GCC_COMPATIBLE to a separate fileJohn Brawn2015-09-293-8/+14
| | | | | | | | | | | | 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
* [CMake] Adding ALWAYS_GENERATE option to symlink utility functions.Chris Bieneman2015-09-181-20/+33
| | | | | | This implements the behavior required for clang symlinks which should be always generated. llvm-svn: 248039
* [CMake] More cleanup of installing symlinks.Chris Bieneman2015-09-182-1/+7
| | | | | | | | 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
* [CMake] More refactoring of symlink creation.Chris Bieneman2015-09-161-11/+17
| | | | | | This refactoring is to enable clang to re-use this code. llvm-svn: 247850
* [CMake] Rename target->dest as per feedback from Chapuni on ↵Chris Bieneman2015-09-151-10/+10
| | | | | | http://reviews.llvm.org/D12864 llvm-svn: 247658
* [CMake] Refactor and cleanup generating and installing symlinks to tools.Chris Bieneman2015-09-142-0/+76
| | | | | | | | | | | | 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
* [CMake] s/LLVM_SOURCE_DIR/LLVM_MAIN_SRC_DIR/Jordan Rose2015-09-101-1/+1
| | | | | | | | 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
* [CMake] Allow LLVM_TOOLCHAIN_TOOLS to be overriddenChris Bieneman2015-09-101-5/+6
| | | | llvm-svn: 247306
* [CMake] Fix Xcode build with LLVM_ENABLE_OBJLIB.Jordan Rose2015-09-101-0/+6
| | | | | | | | | | | | | 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
* Silencing C4141 warnings that were introduced en masse because __forceinline ↵Aaron Ballman2015-09-101-0/+1
| | | | | | 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
* [CMake] Flag recursive cmake invocations for cross-compileJoseph Tremoulet2015-09-091-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | 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
* [CMake][CMP0051] Avoid for user of objlib to use llvm_update_compile_flags().NAKAMURA Takumi2015-09-081-2/+8
| | | | | | $<TARGET_OBJECTS> shouldn't require compile flags. Flags are set in obj.${name}. llvm-svn: 246984
* [cmake] rework LLVM_LINK_LLVM_DYLIB option handlingAndrew Wilkins2015-09-053-14/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [CMake] Don't use OBJLIB on Xcode.NAKAMURA Takumi2015-09-021-2/+4
| | | | | | I got a few reports it didn't work. llvm-svn: 246629
* cmake: Error instead of warning and dropping invalid LLVM_USE_SANITIZERJustin Bogner2015-09-011-3/+3
| | | | | | | | | | | | | 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
* Enable linking tools, shared libraries against libLLVMAndrew Wilkins2015-09-012-10/+33
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [CMake] Fix build on MSVC in r246156.NAKAMURA Takumi2015-08-281-1/+2
| | | | | | add_windows_version_resource_file() affects ALL_FILES. OBJLIB shouldn't have *.obj as SOURCES. llvm-svn: 246241
* [CMake] OBJLIB-ize *-tblgen.NAKAMURA Takumi2015-08-272-0/+17
| | | | | | | | | | | | This improves dependency chain of; (LLVMSupport && LLVMTableGen) && (*.cpp in *-tblgen) && (linking *-tblgen) with; (LLVMSupport && LLVMTableGen && *.cpp) && (linking *-tblgen) llvm-svn: 246156
* [cmake] Pass /manifest:no to the linker when asan is enabledReid Kleckner2015-08-251-1/+5
| | | | | | This is a workaround for PR24476. llvm-svn: 245945
* [CMake] add_llvm_external_project: Just warn about nonexistent directories.NAKAMURA Takumi2015-08-221-1/+5
| | | | | | These entries were generated accidentally. llvm-svn: 245783
* [CMake] Make LLVM_EXTERNAL_*_SOURCE_DIR consistent against older buildsites.NAKAMURA Takumi2015-08-221-20/+24
| | | | | | | | | | | | | | | | | | 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
* Filter libraries that are not installed out of CMake exports (currentlyDan Liew2015-08-211-5/+1
| | | | | | | | | | | | | | | | 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
* llvm-build: Adopt generation of LLVM_LIBS_TO_EXPORT. Patch byDan Liew2015-08-211-13/+0
| | | | | | | | | | | | | | | | | 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 #24154 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
* Disable Visual C++ 2013 Debug mode assert on null pointer in some STL ↵Yaron Keren2015-08-211-0/+6
| | | | | | | | | | | | | | | 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
* [cmake] Start adding support for LLVM_USE_SANITIZER=Address on WindowsReid Kleckner2015-08-141-10/+31
| | | | | | Pass "-fsanitize=address" to the compiler and "-debug" to the linker. llvm-svn: 245070
* Use /Zc:inline when building with MSVC.Rafael Espindola2015-08-121-0/+2
| | | | | | | This reduces the total .obj size when building llvm from 496,690,342 to 219,334,936 bytes. llvm-svn: 244767
* Revert "[cmake] Add helper for finding potentially external projects"Reid Kleckner2015-08-111-17/+0
| | | | | | | | | | 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
* [cmake] Add helper for finding potentially external projectsReid Kleckner2015-08-111-0/+17
| | | | | | | 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
* Use a specified list of languages in cmake project() command.Douglas Katzman2015-07-281-0/+1
| | | | | | | | | | | 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
* Avoid using -Wl,-z,defs on Cygwin.Yaron Keren2015-07-231-1/+1
| | | | | | | | | | | | 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
* [CMake] Projects supported via LLVM_EXTERNAL_*_SOURCE_DIR need to be ↵Chris Bieneman2015-07-211-10/+0
| | | | | | | | 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
* [cmake] pass GO_EXECUTABLE to llgo-goAndrew Wilkins2015-07-211-1/+1
| | | | | | | | | | | | | | | | 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
* [CMake] Fixing inconsistency caused by copy-pasta.Chris Bieneman2015-07-211-2/+2
| | | | | | This will actually fix the PR 24194. llvm-svn: 242748
* [CMake] Fixing a problem with external projects that aren't getting enabled ↵Chris Bieneman2015-07-211-0/+4
| | | | | | | | properly. This should address PR 24194, and some builedbot failures. llvm-svn: 242746
* Suppress two warnings from MSVC 2015 that are triggered under /W4. Since we ↵Aaron Ballman2015-07-201-0/+2
| | | | | | turn off exceptions in the code base, C4577 is moot. C4091 triggers on system headers and is a benign construct. llvm-svn: 242708
* [CMake] Cleanup tools/CMakeLists.txt to take advantage of the ↵Chris Bieneman2015-07-201-28/+63
| | | | | | | | | | | | | | | | | | | | | 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
* [CMake] Unbreak add_llvm_external_project when external projects are specified.NAKAMURA Takumi2015-07-141-0/+3
| | | | | | | | 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
* [CMake] Forgot to quote the first part of STREQUAL.Chris Bieneman2015-07-141-1/+1
| | | | llvm-svn: 242103
* [CMake] We shouldn't be storing values in the cache unless they actually ↵Chris Bieneman2015-07-141-4/+9
| | | | | | | | | | | | 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
* Revert "[CMake] Cleanup tools/CMakeLists.txt to take advantage of the ↵Chris Bieneman2015-07-131-64/+21
| | | | | | | | 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
* [CMake] Cleanup tools/CMakeLists.txt to take advantage of the ↵Chris Bieneman2015-07-131-21/+64
| | | | | | | | | | | | | | | | | | | 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
* Revert r241621, "[CMake] Cleanup tools/CMakeLists.txt to take advantage of ↵NAKAMURA Takumi2015-07-081-31/+19
| | | | | | | | the auto-registration that was already partially working." It broke the build that relies on LLVM_EXTERNAL_CLANG_*. llvm-svn: 241663
* [CMake] Cleanup tools/CMakeLists.txt to take advantage of the ↵Chris Bieneman2015-07-071-19/+31
| | | | | | | | | | | | | | | | | | | | | 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
* [CMake] add_llvm_symbol_exports: Use Python oneliner instead of "cmd.exe /c ↵NAKAMURA Takumi2015-07-051-13/+2
| | | | | | type" to generate *.def. llvm-svn: 241402
* [CMake] Make the CMake files (LLVMConfig.cmake and LLVMExports.cmake)Dan Liew2015-06-301-9/+27
| | | | | | | | | | | | | | | | | | generated by the Autoconf/Makefile build system relocatable. Previously the generated CMake files contained hardcoded paths which prevented a binary installation from being relocated to a different place in the file system. This problem was most noticeable in LLVM's official binary releases which were completely unusable by a downstream project trying to import the CMake targets. Package maintainers who choose to modify the install location of the CMake directory without using the ``PROJ_cmake`` Makefile variable override will need to patch the generated``LLVMConfig.cmake`` so that ``LLVM_INSTALL_PREFIX`` and ``_LLVM_CMAKE_DIR`` variables are set correctly. llvm-svn: 241080
* Fix bug #23967. The gtest and gtest_main targets were exported into theDan Liew2015-06-292-3/+16
| | | | | | | | | | | | | | | | | | | CMake files and should not be by both build systems and also the targets were also installed by the CMake build system which they should not be. The problem was that - the CMake build of LLVM installs and exports the gtest library targets. We should not being doing this, these are not part of LLVM. - the Autoconf/Makefile build of LLVM still had gtest libraries in the installed LLVMConfig.cmake. These problems would cause problems for an external project because when calling llvm_map_components_to_libnames(XXX all) ${XXX} would to contain LLVM's internal gtest libraries. llvm-svn: 240981
* Spelling fixes in comments.Douglas Katzman2015-06-241-2/+2
| | | | llvm-svn: 240594
OpenPOWER on IntegriCloud