[LLVMdev] Let's not depend on terminfo / curses?

[Nico Weber]

Hi,

llvm recently switched to using terminfo for detecting if terminals support escape codes. There's some discussion about this after the commit happened here:

http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20130805/183590.html

After the discussion, it looks like the approach was switched from depending on curses on just terminfo. From what I gather (the changelog didn't say), the motivation for this is that depending on curses is better than printing escape codes in terminals that don't support them.

I think depending on curses is gross, and there haven't been many complaints about clang printing escape codes during the years it has existed so far. Other projectsget by with isatty() && !strcmp(getenv("TERM"), "dumb") too, for example git:

https://github.com/git/git/blob/21ff9151e811059f5576ca906c519ee5bb5b925e/color.c#L183


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?

(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?)

Thanks,
Nico

[Joerg Sonnenberger]

On Sun, Sep 08, 2013 at 05:09:57PM -0700, Nico Weber wrote:
> I think depending on curses is gross, and there haven't been many
> complaints about clang printing escape codes during the years it has
> existed so far. Other projectsget by with isatty() &&
> !strcmp(getenv("TERM"), "dumb") too, for example git:

Tools in the GNU/Linux environment have a long history of hard coding
escape sequences. GNU ls is a good example. That doesn't mean it is the
correct thing to do. So far, I haven't heard a valid (or even any
argument at all) from you to change that. The Windows case is somewhat
different due to the cruft of the Windows console API...

Joerg
_______________________________________________
LLVM Developers mailing list
LLV...@cs.uiuc.edu http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

[Renato Golin]

On 9 September 2013 01:09, Nico Weber <tha...@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. Even though curses is available on pretty much every OS, there are hacks you have to do to port across OSs, especially 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? 

(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.

cheers,

--renato

[Nico Weber]

On Mon, Sep 9, 2013 at 12:24 AM, Renato Golin <renato...@linaro.org> wrote:

On 9 September 2013 01:09, Nico Weber <tha...@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. 

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.

[Renato Golin]

On 12 September 2013 16:34, Nico Weber <tha...@chromium.org> wrote:

I'd still like to do this part. Let me know if you object to it.

I don't. Some people might not like it to be default to "no", but I don't either.

cheers,

--renato

[Benjamin Kramer]

On 12.09.2013, at 17:34, Nico Weber <tha...@chromium.org> wrote:

> On Mon, Sep 9, 2013 at 12:24 AM, Renato Golin <renato...@linaro.org> wrote:
> On 9 September 2013 01:09, Nico Weber <tha...@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.

- Ben

>
> 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.
>
> cheers,
> --renato
>
>
>

[Joerg Sonnenberger]

On Thu, Sep 12, 2013 at 08:34:59AM -0700, Nico Weber wrote:
> Given that things worked fine so far, I guess most people are not using old
> Unices.

On old Unices, you already have far greater problems than building any
form of curses to get this far.

Joerg