Integrating editline with ghc

[Simon Marlow]

Judah Jacobson wrote:
> On Jan 27, 2008 6:23 PM, Manuel M T Chakravarty <chak at cse.unsw.edu.au> wrote:
>> Ian Lynagh:
>>> 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
>> 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