summaryrefslogtreecommitdiffstats
path: root/llvm/cmake/modules/LLVMConfig.cmake.in
Commit message (Collapse)AuthorAgeFilesLines
* Make LLVM_APPEND_VC_REV=OFF affect clang, lld, and lldb as well.Nico Weber2020-06-231-0/+2
| | | | | | | | | | | | | | | | | | When LLVM_APPEND_VC_REV=OFF is set, the current git hash is no longer embedded into binaries (mostly for --version output). Without it, most binaries need to relink after every single commit, even if they didn't change otherwise (due to, say, a documentation-only commit). LLVM_APPEND_VC_REV is ON by default, so this doesn't change the default behavior of anything. With this, all clients of GenerateVersionFromVCS.cmake honor LLVM_APPEND_VC_REV. Differential Revision: https://reviews.llvm.org/D72855 (cherry picked from commit fb5fafb23cc2d8613f8be2487afe94d8594a88ce)
* [compiler-rt] Disable fuzzer large.test when LLVM_ENABLE_EXPENSIVE_CHECKS=ONAlex Lorenz2019-12-031-0/+2
| | | | | | | | | | | | | This test is timing out on Green Dragon http://green.lab.llvm.org/green/job/clang-stage1-cmake-RA-expensive/ and looks like it's not executed on other bots with expensive checks enabled http://lab.llvm.org:8011/builders/llvm-clang-x86_64-expensive-checks-ubuntu http://lab.llvm.org:8011/builders/llvm-clang-x86_64-expensive-checks-win The test times out at the C++ source file takes too long to build (2+ hours on my machine), as clang spends a lot of time in IR/MIR verifiers. Differential Revision: https://reviews.llvm.org/D70024
* build: serialise `LLVM_ENABLE_UNWIND_TABLES` into LLVMConfigSaleem Abdulrasool2019-09-301-0/+2
| | | | | | | | | Serialize the value of the configuration option into the configuration so that builds which integrate LLVM can identify the value of the flag that was used to build the libraries. This is intended to be used by Swift to control tests which rely on the unwind information. llvm-svn: 373253
* [llvm] [cmake] Add possibility to use ChooseMSVCCRT.cmake when include LLVM ↵Simon Pilgrim2019-09-231-0/+5
| | | | | | | | | | | | library Modify LLVMConfig to produce LLVM_USE_CRT variables in build-directory. It helps to set the same compiler debug options like in builded library. Committed on behalf of @igorban (Igor) Differential Revision: https://reviews.llvm.org/D67175 llvm-svn: 372610
* [lit] Only set DYLD_LIBRARY_PATH for shared buildsJonas Devlieghere2019-08-301-0/+1
| | | | | | | | | | | | In r370135 I committed a temporary workaround for the sanitized bot to not set (DY)LD_LIBRARY_PATH when (DY)LD_INSERT_LIBRARIES was set. Setting (DY)LD_LIBRARY_PATH is only necessary for (standalone) shared-library builds, so a better solution is to only set the environment variable when necessary. Differential revision: https://reviews.llvm.org/D67012 llvm-svn: 370549
* [CMake] Export CMAKE_CONFIGURATION_TYPES for the LLVM build-treeStefan Granitz2019-06-051-0/+1
| | | | | | | | | | | | | | Summary: Useful info for standalone builds of subprojects. If a multi-configuration generator was used for the provided LLVM build-tree, standalone builds should consider actual subdirectories per configuration in `find_program()` (e.g. looking for `llvm-lit` or `llvm-tblgen`). Reviewers: labath, beanz, mgorny Subscribers: lldb-commits, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D62878 llvm-svn: 362588
* Moved everything SMT-related to LLVM and updated the cmake scripts.Mikhail R. Gadelha2019-03-251-0/+2
| | | | | | Differential Revision: https://reviews.llvm.org/D54978 llvm-svn: 356929
* [llvm] [cmake] Provide split include paths in LLVMConfigMichal Gorny2019-02-131-4/+6
| | | | | | | | | | | | | | | | Modify LLVMConfig to provide split variables for in-source and generated include paths. Currently, it uses a single value for both LLVM_INCLUDE_DIRS and LLVM_INCLUDE_DIR which works for install tree but fails hard at build tree (where LLVM_INCLUDE_DIR incorrectly contains multiple values). Instead, put the generated directory in LLVM_INCLUDE_DIR, and the source tree in LLVM_MAIN_INCLUDE_DIR which is consistent with in-LLVM builds. For install tree, both variables will have the same value. Differential Revision: https://reviews.llvm.org/D58109 llvm-svn: 353924
* This reverts commit 1440a848a635849b97f7a5cfa0ecc40d37451f5b.Mikhail R. Gadelha2019-02-091-2/+0
| | | | | | | | and commit a1853e834c65751f92521f7481b15cf0365e796b. They broke arm and aarch64 llvm-svn: 353590
* Move the SMT API to LLVMMikhail R. Gadelha2019-02-071-0/+2
| | | | | | | | Moved everything SMT-related to LLVM and updated the cmake scripts. Differential Revision: https://reviews.llvm.org/D54978 llvm-svn: 353373
* cmake: Store LLVM_VERSION_SUFFIX in LLVMConfig.cmakeMichal Gorny2018-08-081-0/+1
| | | | | | | | | | | | | | | | Store LLVM_VERSION_SUFFIX along with other version components in LLVMConfig.cmake. This fixes preserving the suffix set while building LLVM to stand-alone builds of other components, e.g. clang, and therefore improves uniformity between the two build models. Given that there is no apparent reason to omit this part of version, that it is distributed to subprojects when building as part of LLVM and that it is included in LLVM_PACKAGE_VERSION, I think it was omitted accidentally rather than done on purpose. Differential Revision: https://reviews.llvm.org/D43701 llvm-svn: 339285
* [CMake] Followup for r337366: Only export LLVM_LINK_LLVM_DYLIB if it's set to ONPhilip Pfaffe2018-07-271-1/+1
| | | | | | | | | | | | | | | | | | Summary: As it was, always exporting LLVM_LINK_LLVM_DYLIB caused out-of-tree clients to lose the ability to link against the dylib, even if in-tree tools did not. By only exporting the setting if it is enabled, out-of-tree clients get the correct default, but may still choose if they can. Reviewers: mgorny, beanz, labath, bogner, chandlerc Reviewed By: bogner, chandlerc Subscribers: bollu, llvm-commits Differential Revision: https://reviews.llvm.org/D49843 llvm-svn: 338119
* [CMake] Export the LLVM_LINK_LLVM_DYLIB settingPhilip Pfaffe2018-07-181-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: When building out-of-tree tools, there are several macros available to automate linking against llvm. An examples is `add_llvm_executable`, or the clang variant of this. These macros use the LLVM_LINK_LLVM_DYLIB option to decide whether to link against libraries defined by setting LLVM_LINK_COMPONENTS or to link against libLLVM instead. Currently this is problematic in out-of-tree targets, because they cannot identify whether this option is required or even available. If the option was enabled in LLVM's own build, the clang libraries are built against libLLVM, so a client linking against those must link against it too. On the other hand the client can't just always link against it, because it might not be available. This is related to D44391, but that change assumed the client knew whether they wanted the dylib or not. Reviewers: mgorny, beanz, labath Reviewed By: mgorny Subscribers: bollu, llvm-commits Differential Revision: https://reviews.llvm.org/D49193 llvm-svn: 337366
* Stop setting LLVM_ON_WIN32 in config.h and llvm-config.h.Nico Weber2018-04-301-1/+0
| | | | | | | | | | | | | | See thread "Replacing LLVM_ON_WIN32 with just _WIN32" on llvm-dev and cfe-dev. I replaced all uses of LLVM_ON_WIN32 with _WIN32 in r331127 (llvm), r331069 (clang), r329697 (lldb), r329696 (lld), r329696 (clang-tools-extra). If your out-of-tree program used LLVM_ON_WIN32, just use _WIN32 instead, which is set at exactly the same time to exactly the same value. https://reviews.llvm.org/D46264 llvm-svn: 331224
* Export LLVM_DYLIB_COMPONENTS in LLVMConfig.cmakePavel Labath2018-03-141-0/+2
| | | | | | | | | | | | | | | | | Summary: This is needed so that external projects (e.g. a standalone build of lldb) can link to the LLVM shared library via the USE_SHARED argument of llvm_config. Without this, llvm_config would add LLVM to the link list, but then also add the constituent static libraries, resulting in multiply defined symbols. Reviewers: beanz, mgorny Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D44391 llvm-svn: 327484
* [cmake] Include LLVM_LIBXML2_ENABLED in LLVMConfig.cmake, PR36006Michal Gorny2018-01-191-0/+2
| | | | | | | | | | Include the LLVM_LIBXML2_ENABLED cache variable in LLVMConfig.cmake in order to make it available for other LLVM packages to query. This is necessary to fix stand-alone testing of LLD. Differential Revision: https://reviews.llvm.org/D42252 llvm-svn: 322973
* [cmake] Expose opt-viewer availabilityAdam Nemet2017-12-011-0/+1
| | | | | | This will be used in https://github.com/apple/swift/pull/12938 llvm-svn: 319511
* [CMake] NFC. Add intrinsics_gen target to CMake ExportsChris Bieneman2017-07-281-0/+7
| | | | | | By creating a dummy of this target in LLVMConfig.cmake, projects that can build against out-of-tree LLVM can freely depend on the target without needing to have conditionals for if LLVM is in-tree or out-of-tree. llvm-svn: 309389
* [CMake] Fix pthread handling for out-of-tree buildsEric Fiselier2017-02-101-0/+4
| | | | | | | | | | | | | | | LLVM defines `PTHREAD_LIB` which is used by AddLLVM.cmake and various projects to correctly link the threading library when needed. Unfortunately `PTHREAD_LIB` is defined by LLVM's `config-ix.cmake` file which isn't installed and therefore can't be used when configuring out-of-tree builds. This causes such builds to fail since `pthread` isn't being correctly linked. This patch attempts to fix that problem by renaming and exporting `LLVM_PTHREAD_LIB` as part of`LLVMConfig.cmake`. I renamed `PTHREAD_LIB` because It seemed likely to cause collisions with downstream users of `LLVMConfig.cmake`. llvm-svn: 294690
* [CMake] Fix standalone project builds broken in r294514Chris Bieneman2017-02-091-0/+1
| | | | | | This patch sets the global property indicating that target registration is complete for standalone sub-project builds. llvm-svn: 294602
* [cmake] Add LLVM_ENABLE_DIA_SDK option, and expose it in LLVMConfigMichal Gorny2017-01-021-0/+2
| | | | | | | | | | | | | | | Add an explicit LLVM_ENABLE_DIA_SDK option to control building support for DIA SDK-based debugging. Control its value to match whether DIA SDK support was found and expose it in LLVMConfig (alike LLVM_ENABLE_ZLIB). Its value is needed for LLDB to determine whether to run tests requiring DIA support. Currently it is obtained from llvm/Config/config.h; however, this file is not available for standalone builds. Following this change, LLDB will be modified to use the value from LLVMConfig. Differential Revision: https://reviews.llvm.org/D26255 llvm-svn: 290818
* [cmake] Export gtest/gtest_main and its dependencies via a special build ↵Michael Gottesman2016-09-091-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | tree only cmake exports file. Previously, gtest/gtest_main were not exported via cmake. The intention here was to ensure that users whom are linking against the LLVM install tree would not get the gtest/gtest_main targets. This prevents downstream projects that link against the LLVM build tree (i.e. Swift) from getting this dependency information in their cmake builds. Without such dependency information, linker issues can result on linux due to LLVMSupport being put before gtest on the linker command line. This commit preserves behavior that we want for the install tree, while adding support for the build tree by: 1. The special casing for gtest/gtest_main in the add_llvm_library code is removed in favor of a flag called "BUILDTREE_ONLY". If this is set, then the library is communicating that it is only meant to be exported into the build tree and is not meant to be installed or exported via the install tree. This part is just a tweak to remove the special case, the underlying code is the same. 2. The cmake code that exports cmake targets for the build tree has special code to import an additional targets file called LLVMBuildTreeOnlyExports.cmake. Additionally the extra targets are added to the LLVMConfig.cmake's LLVM_EXPORTED_TARGETS variable. In contrast, the "installation" cmake file uses the normal LLVM_EXPORTS_TARGETS as before and does not include the extra exports file. This is implemented by defining/undefining variables when performing a configure of the build/install tree LLVMConfig.cmake files. llvm-svn: 281085
* [CMake] Revive LLVM_*_DIRS variablesChris Bieneman2016-09-011-0/+7
| | | | | | | | This is a partial revert of r280013. Brad King pointed out these variable names are matching CMake conventions, so we should preserve them. I've also added a direct mapping of the LLVM_*_DIR variables which we need to make projects support building in and out of tree. llvm-svn: 280380
* [CMake] Make LLVMConfig.cmake variable names match in-tree namesChris Bieneman2016-08-291-2/+1
| | | | | | | | | | | | With the runtimes build we're trying to use LLVMConfig.cmake as a way of providing LLVM_* variables that are needed to behave as if the project is building in tree. To make this work we need to rename two variables by dropping the "S" from the end. This makes the variables match the in-tree names. This renames: LLVM_INCLUDE_DIRS -> LLVM_INCLUDE_DIR LLVM_LIBRARY_DIRS -> LLVM_LIBRARY_DIR The versions ending in S are not used in-tree anywhere. This also cleans up LLVM_LIBRARY_DIR being set to the same value with and without the "S". llvm-svn: 280013
* [CMake] Add LLVM_BUILD_32_BITS to LLVMConfig.cmakeJohn Brawn2016-07-011-0/+2
| | | | | | | | | | | Previously out-of-tree passes could detect if LLVM was built with LLVM_BUILD_32_BITS by looking for -m32 in LLVM_DEFINITIONS, but as of r271871 it no longer appears there. Resolve this by instead emitting LLVM_BUILD_32_BITS in LLVMConfig so it can be checked for directly. Differential Revision: http://reviews.llvm.org/D21434 llvm-svn: 274351
* [LLVMConfig.cmake] LLVM_CONFIG_EXPORTED_TARGETS => LLVM_EXPORTED_TARGETS.Michael Gottesman2016-06-291-1/+1
| | | | | | | This matches more closely the rest of the variables in LLVMConfig.cmake which shed the _CONFIG_ part of their names. llvm-svn: 274175
* [LLVMConfig.cmake.in] Create a new variable LLVM_CONFIG_EXPORTED_TARGETS ↵Michael Gottesman2016-06-291-0/+1
| | | | | | that contains the list of all targets exported via LLVMExports.cmake. llvm-svn: 274140
* [cmake] Port the llvm-config option --build-mode to LLVMConfig.cmake via the ↵Michael Gottesman2016-06-251-0/+2
| | | | | | | | | | | | variable LLVM_BUILD_TYPE. This is just a small step in the direction of making LLVMConfig.cmake a complete replacement for llvm-config. For those unfamiliar, llvm-config --build-mode prints out CMAKE_BUILD_TYPE. Thus as one can imagine, LLVM_BUILD_TYPE is @CMAKE_BUILD_TYPE@. llvm-svn: 273782
* [CMake] LLVM_BINARY_DIR was not being properly set in LLVMConfig.cmakeChris Bieneman2016-06-221-1/+1
| | | | | | LLVMConfig.cmake needs to set LLVM_BINARY_DIR differently based on whether or not it is the build directory or the install directory. The build directory just needs to set the value from the configuration, the install directory needs to set it to the install prefix. llvm-svn: 273479
* [CMake] Add LLVM_TOOLS_INSTALL_DIR to LLVMConfig.cmakeChris Bieneman2016-06-091-0/+1
| | | | | | This is the more-correct fix to out-of-tree building. AddLLVM.cmake relies on this variable being set, so we should make sure it is set in LLVMConfig.cmake. llvm-svn: 272279
* Add auto-exporting of symbols from tools so that plugins work on WindowsJohn Brawn2016-05-261-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | The problem with plugins on Windows is that when building a plugin DLL it needs to explicitly link against something (an exe or DLL) if it uses symbols from that thing, and that thing must explicitly export those symbols. Also there's a limit of 65535 symbols that can be exported. This means that currently plugins only work on Windows when using BUILD_SHARED_LIBS, and that doesn't work with MSVC. This patch adds an LLVM_EXPORT_SYMBOLS_FOR_PLUGINS option, which when enabled automatically exports from all LLVM tools the symbols that a plugin could want to use so that a plugin can link against a tool directly. Plugins can specify what tool they link against by using PLUGIN_TOOL argument to llvm_add_library. The option can also be enabled on Linux, though there all it should do is restrict the set of symbols that are exported as by default all symbols are exported. This option is currently OFF by default, as while I've verified that it works with MSVC, linux gcc, and cygwin gcc, I haven't tried mingw gcc and I have no idea what will happen on OSX. Also unfortunately we can't turn on LLVM_ENABLE_PLUGINS when the option is ON as bugpoint-passes needs to be loaded by both bugpoint.exe and opt.exe which is incompatible with this approach. Also currently clang plugins don't work with this approach, which will be fixed in future patches. Differential Revision: http://reviews.llvm.org/D18826 llvm-svn: 270839
* [CMake] Add some extra variables to LLVMConfig.cmake.inChris Bieneman2016-05-101-0/+2
| | | | | | | | Compiler-RT needs LLVM_LIBRARY_DIR, LLVM_BINARY_DIR. Setting these in LLVMConfig.cmake will allow Compiler-RT to not need to run llvm-config as long as the LLVMConfig.cmake module is in the CMake module path. llvm-svn: 269104
* [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] Uniquify LLVM_ABI_BREAKING_CHECKS. It reverts r233784, "[CMake] ↵NAKAMURA Takumi2015-04-131-2/+0
| | | | | | Cache in LLVMConfig.cmake." llvm-svn: 234720
* Try to unbreak Clang build to export LLVM_ABI_BREAKING_CHECKS, fixup for ↵NAKAMURA Takumi2015-04-011-0/+2
| | | | | | | r233310. FIXME: Should ENABLE_ABI_BREAKING_CHECKS be tri-state, "ON/OFF/blank"? llvm-svn: 233801
* [CMake] Cache LLVM_ABI_BREAKING_CHECKS in LLVMConfig.cmake.Sanjoy Das2015-04-011-0/+2
| | | | | | Not having this breaks clang builds that use an already-built LLVM. llvm-svn: 233784
* [cmake] Push LLVM_LIBDIR_SUFFIX through to the LLVMConfig.cmake fileChandler Carruth2014-12-291-0/+2
| | | | | | | | | that is used by other projects to build against LLVM. This will allow subsequent patches to them to use LLVM_LIBDIR_SUFFIX, both when built as part of the larger LLVM build an as part of a standalone build against an installed set of LLVM libraries. llvm-svn: 224920
* Add LLVM_TOOLS_BINARY_DIR variable to LLVMConfig.cmake so clientsDan Liew2014-07-221-0/+1
| | | | | | | | | of LLVM using CMake can easily find the tools directory. LLVM_BUILD_TOOLS_BINARY_DIR was removed because it is now superfluous. llvm-svn: 213674
* Export LLVM_ENABLE_RTTI and LLVM_ENABLE_EH in LLVMConfig.cmake soDan Liew2014-07-221-0/+4
| | | | | | | clients of LLVM know if RTTI and/or EH were enabled in the build of LLVM they are trying to link against. llvm-svn: 213664
* Export LLVM_ENABLE_ASSERTIONS in LLVMConfig.cmake so clients knowDan Liew2014-07-211-0/+2
| | | | | | | if the version of LLVM they are trying to use was built with or without assertions. llvm-svn: 213532
* Add support for a patch version to the cmake system.Eric Christopher2014-04-161-0/+1
| | | | | | Patch by Brad King llvm-svn: 206425
* Simplify linking to system librariesNAKAMURA Takumi2014-02-231-5/+0
| | | | | | | | | | | | | | | | | | | | | | | | | The LLVMSupport library implementation consolidates all dependencies on system libraries. Move the logic gathering system libraries out of 'cmake/modules/LLVM-Config.cmake' and into 'lib/Support/CMakeLists.txt'. Use the target_link_libraries() command there to tell CMake about the link dependencies of the LLVMSupport implementation. CMake will automatically propagate this to all targets that link LLVMSupport directly or indirectly. We still need to build knowledge of system library dependencies into 'llvm-config'. Store the list of libraries needed in a property on LLVMSupport and teach 'tools/llvm-config/CMakeLists.txt' to retrieve it from there. Drop all calls to 'link_system_libs' and 'get_system_libs' from our CMake code. Replace their implementations with a warning that explains the calls are no longer necessary. Also drop from 'LLVMConfig.cmake' the HAVE_* and related variables that were published there only to allow 'get_system_libs' to run outside our build process. Contributed by Brad King. llvm-svn: 201969
* Teach LLVM-Config to use logical target names (2/2)NAKAMURA Takumi2014-02-211-1/+1
| | | | | | | | | | | | | The module still needs to collect the list of all available libraries in order to satisfy the 'all' component. Provide this in the package configuration file, 'LLVMConfig.cmake', as a LLVM_AVAILABLE_LIBS variable. (A variable is scoped better than a global property.) Since this won't be set for our own build, fall back to looking up the LLVM_LIBS property to get the value when it is not set. Contributed by Brad King. llvm-svn: 201853
* Load exported lib and exe targets from LLVMConfigNAKAMURA Takumi2014-02-091-0/+4
| | | | | | | | | | | | | Teach each package configuration file to load the LLVMExports file for its corresponding tree. This will allow application CMake code to use logical library and executable target names from LLVM as if they were in our own build process (e.g. LLVMSupport). CMake will have enough information to propagate LLVM library link dependencies automatically while configuring applications. Contributed by Brad King. llvm-svn: 201051
* Provide LLVMConfig in both build and install treeNAKAMURA Takumi2014-02-091-6/+6
| | | | | | | | | | | | | | | | | | Create separate package configuration files "LLVMConfig.cmake" for the LLVM build and install trees so that each can have information specific to its tree. Configure each with the corresponding include, lib, and cmake directories. Include the "LLVM-Config" API modules directly from the configured cmake modules directory. In the install tree, compute the installation prefix relative to the file location. In the build tree, provide information specific to the build tree for use by tools like Clang that can build externally against the LLVM build tree. Prefix such values in "LLVM_BUILD_" and comment them as such. Contributed by Brad King. llvm-svn: 201048
* Teach LLVMConfig to avoid modifying CMAKE_MODULE_PATHNAKAMURA Takumi2014-02-091-13/+3
| | | | | | | | | | | | Do not modify this value on the application's behalf and just ensure API modules are always available next to the LLVMConfig module. This is already the case in the install tree so use file(COPY) to make it so in the build tree. Include the LLVM-Config API module from next to the LLVMConfig location. Contributed by Brad King. llvm-svn: 201047
* [CMake] Prune LLVM_TOOLS_BINARY_DIR in LLVMConfig.cmake, since it always ↵NAKAMURA Takumi2013-12-181-2/+0
| | | | | | points build directory. llvm-svn: 197581
* Target a minimal terminfo library rather than necessarily a full cursesChandler Carruth2013-08-121-4/+3
| | | | | | | | | | | | | | | | | | | | library for color support detection. This still will use a curses library if that is all we have available on the system. This change tries to use a smaller subset of the curses library, specifically the subset that is on some systems split off into a separate library. For example, if you install ncurses configured --with-tinfo, a 'libtinfo' is install that provides just the terminfo querying functionality. That library is now used instead of curses when it is available. This happens to fix a build error on systems with that library because when we tried to link ncurses into the binary, we didn't pull tinfo in as well. =] It should also provide an easy path for supporting the NetBSD libterminfo library, but as I don't have access to a NetBSD system I'm leaving adding that support to those folks. llvm-svn: 188160
* Add three missing CMake variables that need to make it to theChandler Carruth2013-08-081-0/+3
| | | | | | | LLVMConfig.cmake file that is (I think) used in the stand-alone Clang build, and causing link errors there w.r.t. curses. llvm-svn: 187950
* Add support for linking against a curses library when available andChandler Carruth2013-08-071-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | using it to detect whether or not a terminal supports colors. This replaces a particularly egregious hack that merely compared the TERM environment variable to "dumb". That doesn't really translate to a reasonable experience for users that have actually ensured their terminal's capabilities are accurately reflected. This makes testing a terminal for color support somewhat more expensive, but it is called very rarely anyways. The important fast path when the output is being piped somewhere is already in place. The global lock may seem excessive, but the spec for calling into curses is *terrible*. The whole library is terrible, and I spent quite a bit of time looking for a better way of doing this before convincing myself that this was the fundamentally correct way to behave. The damage of the curses library is very narrowly confined, and we continue to use raw escape codes for actually manipulating the colors which is a much sane system than directly using curses here (IMO). If this causes trouble for folks, please let me know. I've tested it on Linux and will watch the bots carefully. I've also worked to account for the variances of curses interfaces that I could finde documentation for, but that may not have been sufficient. llvm-svn: 187874
OpenPOWER on IntegriCloud