[LLVMdev] Let's not depend on terminfo / curses?
benny.kra at gmail.com
Thu Sep 12 08:55:11 PDT 2013
On 12.09.2013, at 17:34, Nico Weber <thakis at chromium.org> wrote:
> On Mon, Sep 9, 2013 at 12:24 AM, Renato Golin <renato.golin at linaro.org> wrote:
> On 9 September 2013 01:09, Nico Weber <thakis at chromium.org> wrote:
> I think depending on curses is gross,
> I totally agree, but I also don't have a better way of doing this. I agree with Joerg that hard-coding escape sequences is not the way forward.
> llvm is still hard-coding escape sequences (see Process::OutputBold() etc). As far as I understood, there wasn't a plan to change that. curses is only used to detect if the terminal supports escape codes.
> It sounds like nobody else minds llmv depending on additional libraries, so I'll drop this.
If you really care a lot about the dependency, why not turn it into a soft (dlopen) dependency? We already hardcode all the prototypes of the handful of functions of curses we're using, doing it dynamically wouldn't hurt that much. I'm not sure everyone agrees on that though.
Then LLVM could check for libcurses availability and fall back to git-style detection when it's not around.
> Even though curses is available on pretty much every OS, there are hacks you have to do to port across OSs, especially old Unices.
> Given that things worked fine so far, I guess most people are not using old Unices.
> If folks think that bringing in the decades of cruft in curses is a good idea, I'd ask that the --enable-curses=no --enable-terminfo=no path at least keeps the old logic. Are there any objections to that?
> I'd still like to do this part. Let me know if you object to it.
> (And since there are probably fewer shells on OS X, would anyone mind if --enable-curses=no --enable-terminfo=no was the default on OS X? And since even git can get away with it, maybe on Linux too?)
> If this is *just* for fancy make output, I'd say be gone with it. But Clang could also depend on it for fancy error reporting (does it?),
> which is a different matter. I don't really mind fancy output either way.
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
More information about the llvm-dev