On Jan 22, 2008 1:49 AM, Manuel M T Chakravarty
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
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