[llvm] r187874 - Add support for linking against a curses library when available and

Chandler Carruth chandlerc at google.com
Wed Aug 7 17:01:13 PDT 2013


You seem to feel very strongly about this, and I'd like to understand the
context in addition to the specifics of our argument. Is this a problem in
practice for you or anyone else you know of? Do you have a concrete example
where Clang now does the wrong thing on a particular system?

On Wed, Aug 7, 2013 at 2:42 PM, James Molloy <james at jamesmolloy.co.uk>wrote:

> The difference between zlib and curses is that the dependency on zlib was
> added to support a *new feature*. Without it, you don't get the new
> feature. Fair enough.
>

This may be a new feature to Clang, but it was not really new. This was
absolutely necessary for compatibility with GCC and other things.


> I think it's unreasonable to gate an already existing feature of the user
> interface on a new dependency when there's no clear reason. OK, the old
> algorithm was flaky and had a false positive. So if I, a user or packager,
> care about that I can just now link against libcurses. Sorted.
>
> So why remove the old fallback algorithm when those who care about the
> false positive have a clear and obvious new workaround?
>

The old algorithm wasn't flaky and didn't have "a" false positive. It
assumed that all terminals except for one supported colors. This is pretty
obviously false to me, and we have users that are specifically complaining
about that assumption so I assume it is false in practice.

I don't have any objection to adding fallback special cases for terminals
we know do or don't support colors. (Hence my question about practical
cases that we should handle here) I do have an objection to assuming colors
in the absence of any evidence to indicate that assumption is safe. That
objection is based on the fact that showing colors when they are not valid
causes significantly more harm to the user experience than failing to show
colors when they are valid.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130807/db0aa058/attachment.html>


More information about the llvm-commits mailing list