Let's not depend on terminfo / curses?

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

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

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

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.

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

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

cheers,
--renato

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

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

Joerg