Add support for linking against a curses library when available and

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.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@187874 91177308-0d34-0410-b5e6-96231b3b80d8

1 files changed, 2 insertions, 0 deletions

diff --git a/CMakeLists.txt b/CMakeLists.txt
index 687176ca57..a0a6c75fe7 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -123,6 +123,8 @@ set(FFI_INCLUDE_DIR "" CACHE PATH "Additional directory, where CMake should sear
 set(LLVM_TARGET_ARCH "host"
   CACHE STRING "Set target to use for LLVM JIT or use \"host\" for automatic detection.")
 
+option(LLVM_ENABLE_CURSES "Use curses to detect terminal info if available." ON)
+
 option(LLVM_ENABLE_THREADS "Use threads if available." ON)
 
 option(LLVM_ENABLE_ZLIB "Use zlib for compression/decompression if available." ON)