<div dir="ltr">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.<div><br></div><div style>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.</div>
<div style><br></div><div style>So why remove the old fallback algorithm when those who care about the false positive have a clear and obvious new workaround?</div><div style><br></div><div style>James</div><div style><br>
</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On 7 August 2013 22:32, Chandler Carruth <span dir="ltr"><<a href="mailto:chandlerc@google.com" target="_blank">chandlerc@google.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="im"><br><div class="gmail_quote">On Wed, Aug 7, 2013 at 2:09 PM, James Molloy <span dir="ltr"><<a href="mailto:james@jamesmolloy.co.uk" target="_blank">james@jamesmolloy.co.uk</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr">Hi Chandler,<div><br></div><div>I agree that all unix systems have curses or terminfo. However, it complicates distribution. Now, anyone who wants to package up LLVM or Clang for distribution has to compile and link shared against a version of curses, and the binary compatibility story becomes more complicated. Which version of curses do we use? is there a version that works on a wide range of linux distributions? etc etc.</div>


<div><br></div><div>Previous dependencies such as libxml, zlib have had a graceful fallback. I don't see why this should be any different. Why kill the functionality of autodetecting without linking to an external library if it's cheap to keep?</div>

</div></blockquote></div><br></div>I think libxml, zlib, and curses are no different here. They all provide optional functionality. Without curses, we previously had bad behavior that caused escape codes in places that couldn't handle them, and now have a missing feature of color in a place we would like it. Without zlib, we have a missing feature of compressed debug info in a place we would like it.</div>

<div class="gmail_extra"><br></div><div class="gmail_extra">I don't think this complicates distribution. Note that we build dynamic executables even though we link LLVM's libraries statically. So we already depend on lots of shared libraries:</div>

<div class="gmail_extra"><br></div><div class="gmail_extra"><div class="gmail_extra">% ldd bin/clang</div><div class="gmail_extra">        linux-vdso.so.1 =>  (0x00007fff81dad000)</div><div class="gmail_extra">        librt.so.1 => /lib64/librt.so.1 (0x00007f581ce56000)</div>

<div class="gmail_extra">        libdl.so.2 => /lib64/libdl.so.2 (0x00007f581cc52000)</div><div class="gmail_extra">        libncurses.so.5 => /lib64/libncurses.so.5 (0x00007f581c9fe000)</div><div class="gmail_extra">

        libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f581c7e1000)</div><div class="gmail_extra">        libz.so.1 => /lib64/libz.so.1 (0x00007f581c5cb000)</div><div class="gmail_extra">        libstdc++.so.6 => /usr/lib/gcc/x86_64-pc-linux-gnu/4.6.2/libstdc++.so.6 (0x00007f581c2c1000)</div>

<div class="gmail_extra">        libm.so.6 => /lib64/libm.so.6 (0x00007f581c03f000)</div><div class="gmail_extra">        libgcc_s.so.1 => /usr/lib/gcc/x86_64-pc-linux-gnu/4.6.2/libgcc_s.so.1 (0x00007f581be29000)</div>

<div class="gmail_extra">        libc.so.6 => /lib64/libc.so.6 (0x00007f581baa0000)</div><div class="gmail_extra">        /lib64/ld-linux-x86-64.so.2 (0x00007f581d05f000)</div><div class="gmail_extra"><br></div><div class="gmail_extra">

I don't think anyone has had a problem with librt, libdl, libpthread, libz, or libm, so I suspect adding libncurses won't cause anything to get worse.</div></div></div>
</blockquote></div><br></div>