Re: Integrating editline with ghc

Judah Jacobson wrote:

On Jan 27, 2008 6:23 PM, Manuel M T Chakravarty wrote:

...

...

I think GHC should just always use editline. We already need to support using an in-tree editline for Windows, so we can also use it on other platforms where editline isn't easily available or is too old. Also supporting readline just makes the build system more complicated for little extra benefit, and also means that there are more configurations to bitrot. Sure if you want to add another library into the tree that's an

Ian Lynagh: option. However, I am not so sure whether it's going to be as easy as with GMP. AFAIK libedit (which is the editline port used in Linux distributions - http://www.thrysoee.dk/editline/) needs (n)curses. Their web page says somebody managed to compile on cygwin, but there is no mention of mingw. So, before committing to use editline/libedit on all platforms, it might be useful to make sure editline compiles fine everywhere.

You may have seen this already, but it looks like libedit doesn't work on mingw: http://www.nabble.com/Re%3A-Integrating-editline-with-ghc-p14925360.html

However, we already don't use readline on mingw, right? So I don't think that should be a strike against using editline exclusively.

Right, we don't compile GHCi against readline on Windows. I have built the readline package on Windows in the past, and even managed to get GHCi working with it, but it seems the MingW I have installed right now doesn't come with readline. IIRC readline on Windows didn't work very well in a normal Windows console. Windows console users already get up/down and primitive editing facilities courtesy of the built-in console support anyway. Personally I'd like to drop readline, if we can. As Ian says, if we leave both options in place that's another configuration variable to test, and something else to go wrong. If it means we have to drag editline into the tree, then that's fine by me - I'm thinking of dragging in gcc's libffi too (it's not GPL, FYI), so we're building up a little family of imported external libraries. Cheers, Simon