Integrating editline with ghc

[Judah Jacobson]

On Jan 22, 2008 1:49 AM, Manuel M T Chakravarty <chak at cse.unsw.edu.au> wrote:
> Simon Marlow:
>
> > I think it would be a bad idea to provide EditReadline as
> > described.  The reason being that this would be a package with a
> > variant license: its license is conditional on how it is built,
> > which makes it that much harder for clients to understand what
> > licensing restrictions apply, and to license themselves
> > appropriately.  (the alternative is to make EditReadline GPL, but
> > that defeats the purpose).
> >
> >
> > I don't even think we've considered variant licenses in Cabal
> > before, and my inclination would be to disallow or at least
> > vigorously discourage it.
>
> I don't like this either.
>
> > So I suggest we just keep readline as it is, and packages that want
> > to use editline can switch at their discretion, using
> > System.Console.Editline.Readline to make porting easier.  In GHC I
> > imagine we'll just switch to using editline.
>
> That's fine if all platforms that by default have readline also have
> editline.  I just checked, Fedora 8 does have both.  How about other
> Linux distros?  What is the situation on Solaris?

A few distros (including Solaris) have libedit version 1.*, which
appears to be too old to provide enough functionality to replace
readline.  From what I can tell, libedit-1 provides the header
<editline.h>, whereas libedit-2 provides <histedit.h> as well as
either <readline/readline.h> or <editline/readline.h>.  (OS X 10.4 and
10.5 have 2.6 and 2.9, respectively.)

>From Christian, who helped me figure out what was going on:
> It looks pretty bad with libedit under non-macs. It's also not on our
> fedora7 machines. Under Solaris I did not find histedit.h
>
> Surely http://www.thrysoee.dk/editline/libedit-20070831-2.10.tar.gz
> could be installed on the platforms or supplied with ghc as a static
> library. With libedit dynamically linked user programs will hardly run,
> though, on non-macs.

-Judah