Integrating editline with ghc

[Manuel M T Chakravarty]

Am 25.01.2008 um 03:44 schrieb 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.

To summarise,

* I don't think it is feasible to entirely drop readline from ghci (as  
some widely used Linux distributions, eg, Fedora 7 and Solaris doesn't  
support sufficiently recent versions of editline).

* We don't seem to want a package with a variant license plus might  
have trouble specifying one with Cabal.

My conclusion:

* The readline package stays as it is (stays GPL).

* We add the new editline package (as a boot package) including  
Editline.Readline as the compatibility layer (is BSD3).

* GHC uses configure magic to pick editline when available and  
readline otherwise.

* Any other software can, at their discretion, choose to support only  
readline, or only editline, or use configure magic similar to GHC.   
This is a bit of extra hassle, but that may be a good thing as it  
forces developers to become aware of the licensing issues they get into.

Simon, what do you think?

Manuel