Proposal: Add --with-libedit flag to the readline package
It would be useful for the readline package to support compiling against the libedit library (which provides a subset of the readline APIs): - libedit is available by default on OS X. - since libedit is BSD-licensed, there are no problems statically linking ghc with it. (This may be useful on Windows.) I propose adding a --with-libedit flag to the readline autoconf script. Without that flag, the package will behave exactly as before, refusing to link against libedit. With that flag, the following behavior occurs: - GNUreadline.framework (OS X - only) is ignored, if present - We try to link with -lreadline, and don't fail if readline is actually libedit. - If it is libedit, we #ifdef out all of the functions not supported by libedit. (these are generally low-level APIs not needed by most applications, including ghci.) Otherwise, if we're linking against GNU readline, we support all the available APIs. Suggested deadline: Jan. 23, 2008. A patch is attached to the trac ticket: http://hackage.haskell.org/trac/ghc/ticket/2028 Thoughts? -Judah
Judah Jacobson"
It would be useful for the readline package to support compiling against the libedit library (which provides a subset of the readline APIs):
- libedit is available by default on OS X. - since libedit is BSD-licensed, there are no problems statically linking ghc with it. (This may be useful on Windows.)
I propose adding a --with-libedit flag to the readline autoconf script. Without that flag, the package will behave exactly as before, refusing to link against libedit. With that flag, the following behavior occurs:
- GNUreadline.framework (OS X - only) is ignored, if present - We try to link with -lreadline, and don't fail if readline is actually libedit. - If it is libedit, we #ifdef out all of the functions not supported by libedit. (these are generally low-level APIs not needed by most applications, including ghci.) Otherwise, if we're linking against GNU readline, we support all the available APIs.
In my opinion, a flag with these effects should be called ``--allow-libedit''. For the flag ``--with-libedit'' I would expect: - We try to link with -ledit first. - Only if that fails, we try whether we can get libedit via -lreadline. - If we cannot get libedit, we fail. This makes it easier to produce libedit-linked binaries on systems that do have libreadline. Wolfram
Hi Judah, On Wed, Jan 09, 2008 at 10:08:20AM -0800, Judah Jacobson wrote:
- If it is libedit, we #ifdef out all of the functions not supported by libedit. (these are generally low-level APIs not needed by most applications, including ghci.) Otherwise, if we're linking against GNU readline, we support all the available APIs.
Thoughts?
I agree with Thorkil's message to the bug report (although I think the library name should be libedit or editline - I'm a bit confused about the relationship of the two). If a Haskell library or program has a build-depends on readline, then it should get the same functions everywhere; otherwise dependencies are meaningless. If a program wants to support both libraries then it can do something like If flag(readline) Build-depends: readline CPP-flags: -DUSING_READLINE Else Build-depends: editline CPP-flags: -DUSING_EDITLINE Of course, a third library could do the above conditional dependency and provide an interface to the intersection of readline and editline's functionalities. Other programs can then use that third library. Thanks Ian
On Jan 11, 2008 7:56 AM, Ian Lynagh
Hi Judah,
On Wed, Jan 09, 2008 at 10:08:20AM -0800, Judah Jacobson wrote:
- If it is libedit, we #ifdef out all of the functions not supported by libedit. (these are generally low-level APIs not needed by most applications, including ghci.) Otherwise, if we're linking against GNU readline, we support all the available APIs.
Thoughts?
I agree with Thorkil's message to the bug report (although I think the library name should be libedit or editline - I'm a bit confused about the relationship of the two).
If a Haskell library or program has a build-depends on readline, then it should get the same functions everywhere; otherwise dependencies are meaningless.
OK, you both have convinced me. I'll get to work on an editline library. (From looking at the documentation such as "man editline", I think that is what it should be named.) I've applied for the project to be hosted on community.haskell.org. Basic features: (let me know if you think I'm wrong here) - Licensed under BSD3 (the readline package itself is licensed under GPL since it links against libreadline). - Link with -ledit (instead of -lreadline). - To start with, provide one module, System.Console.Editline.Readline. That module will be mostly a cut-and-paste of all the functions from System.Console.Readline which are supported by editline (version 5.1, as distributed on OS X 10.4). - In the future, we can provide System.Console.Editline which provides the non-readline APIs. -Judah
Judah Jacobson wrote:
OK, you both have convinced me. I'll get to work on an editline library.
Excellent!
- To start with, provide one module, System.Console.Editline.Readline. That module will be mostly a cut-and-paste of all the functions from System.Console.Readline which are supported by editline (version 5.1, as distributed on OS X 10.4). - In the future, we can provide System.Console.Editline which provides the non-readline APIs.
I would prefer if you call it System.Console.Editline to begin with, even if it doesn't support the full API yet, so we can already start migrating our code. If you want, you can also include System.Console.Editline.Readline to provide some Readline-compatible wrappers for the new API where possible. That might help some people with backward compatibility. But for me that is a lower priority. Thanks, Yitz
On 1/12/08, Yitzchak Gale
Judah Jacobson wrote:
OK, you both have convinced me. I'll get to work on an editline library.
Excellent!
- To start with, provide one module, System.Console.Editline.Readline. That module will be mostly a cut-and-paste of all the functions from System.Console.Readline which are supported by editline (version 5.1, as distributed on OS X 10.4). - In the future, we can provide System.Console.Editline which provides the non-readline APIs.
I would prefer if you call it System.Console.Editline to begin with, even if it doesn't support the full API yet, so we can already start migrating our code.
If you want, you can also include System.Console.Editline.Readline to provide some Readline-compatible wrappers for the new API where possible. That might help some people with backward compatibility. But for me that is a lower priority.
I think you may have misunderstood me; let me clarify what I said above.
The editline library itself provides two C interfaces:
1.
Judah Jacobson wrote:
These two interfaces do not overlap, as far as I can tell... 1. System.Console.Editline 2. System.Console.Editline.Readline For now, I'm only working on #2, since it'll be easier to integrate with ghci
Hmm, I see. I thought that there was some overlap. Well, in that case, the goals of native readline emulation for Mac OS X Tiger and editline support for all platforms do not overlap as much as I thought. Too bad. My point is that editline support for all platforms should be a much higher priority than removing the dependence on readline for one specific version of Mac OS X, in my opinion. So my personal preference - even as a Tiger user - would still be to work on #1 first, even if only on a core subset of features. That would make it possible to write interactive console applications in Haskell when GPL is not appropriate. Right now that is a problem on every platform. If not too hard, the next step would be to migrate GHCi to editline, allowing it to be used in a non-GPL environment on every platform. (Actually, since the ghc command has a -i option, I'm wondering why the BSD-style license on GHC is valid at all until we do this.) The third step would be System.Console.Editline.Readline, which would provide several smaller benefits - an easier migration path from Readline to Editline, an easier way for people who really want the Readline API to make their programs work on more platforms, and easier integration of Readline support on Tiger. Anyway, if you're most excited about the Tiger integration side of things, I'm all for it, go for it! Thanks, Yitz
On 1/12/08, Yitzchak Gale
Judah Jacobson wrote:
These two interfaces do not overlap, as far as I can tell... 1. System.Console.Editline 2. System.Console.Editline.Readline For now, I'm only working on #2, since it'll be easier to integrate with ghci
Hmm, I see. I thought that there was some overlap.
Well, in that case, the goals of native readline emulation for Mac OS X Tiger and editline support for all platforms do not overlap as much as I thought. Too bad.
My point is that editline support for all platforms should be a much higher priority than removing the dependence on readline for one specific version of Mac OS X, in my opinion.
I think that in an effort to clarify matters, I made them more muddled. :-) By "they don't overlap" I meant that neither header (histedit.h vs. readline.h) imports the other and that they can be used independently. But *both* headers are present on *all* distributions of editline, not just Apple's. Implementing #2 is sufficient to getting editline working on all platforms. Sorry for the confusion, -Judah
Hi Judah, Judah Jacobson wrote:
By "they don't overlap" I meant that neither header (histedit.h vs. readline.h) imports the other and that they can be used independently. But *both* headers are present on *all* distributions of editline, not just Apple's. Implementing #2 is sufficient to getting editline working on all platforms.
OK, thanks, but it was me who was not clear. You understand far better than I do how things work at the C API level. I am just trying to point out, as an end user, some additional benefits that your proposed project would provide. And in fact, those benefits are so great that they would far overshadow - for me, at least, and perhaps for many others - the benefits that originally motivated the project. So perhaps you would want to take that into consideration when setting priorities, though in the end of course it's up to you. I think the most important issue is to enable using the Editline API in Haskell on all platforms. That would plug a major hole in the usefulness of Haskell as a language to anyone who is not fully committed to the GPL license. While providing partial Readline API emulation via editline would indeed be helpful in some situations, its value pales in comparison to the value of providing the Editline API, in my opinion. Anyway, great idea. Good luck with this. I am looking forward hearing more. Thanks, Yitz
On 1/13/08, Yitzchak Gale
OK, thanks, but it was me who was not clear.
You understand far better than I do how things work at the C API level. I am just trying to point out, as an end user, some additional benefits that your proposed project would provide. And in fact, those benefits are so great that they would far overshadow - for me, at least, and perhaps for many others - the benefits that originally motivated the project. So perhaps you would want to take that into consideration when setting priorities, though in the end of course it's up to you.
I think the most important issue is to enable using the Editline API in Haskell on all platforms. That would plug a major hole in the usefulness of Haskell as a language to anyone who is not fully committed to the GPL license.
While providing partial Readline API emulation via editline would indeed be helpful in some situations, its value pales in comparison to the value of providing the Editline API, in my opinion.
Anyway, great idea. Good luck with this. I am looking forward hearing more.
Thanks, Yitz
All right, I understand you now. It should be pretty straightforward to export the basics of the editline API, at least, if not the advanced features. I'll try to include that in the initial release of the package. Best wishes, -Judah
Judah Jacobson wrote:
I think that in an effort to clarify matters, I made them more muddled. :-)
By "they don't overlap" I meant that neither header (histedit.h vs. readline.h) imports the other and that they can be used independently. But *both* headers are present on *all* distributions of editline, not just Apple's. Implementing #2 is sufficient to getting editline working on all platforms.
interesting... how do all platforms, even ones with Readline installed in a traditional Unix filesystem layout, manage to distribute Editline also with readline/readline.h? Shouldn't there be a non-overlapping header name that exports the same compatibility interface? ~Isaac
On 1/13/08, Isaac Dupree
Judah Jacobson wrote:
I think that in an effort to clarify matters, I made them more muddled. :-)
By "they don't overlap" I meant that neither header (histedit.h vs. readline.h) imports the other and that they can be used independently. But *both* headers are present on *all* distributions of editline, not just Apple's. Implementing #2 is sufficient to getting editline working on all platforms.
interesting... how do all platforms, even ones with Readline installed in a traditional Unix filesystem layout, manage to distribute Editline also with readline/readline.h? Shouldn't there be a non-overlapping header name that exports the same compatibility interface?
That's a good question; now that I think about it, I'm not sure of the
answer. The header might be renamed, e.g. to
participants (5)
-
Ian Lynagh -
Isaac Dupree -
Judah Jacobson -
kahl＠cas.mcmaster.ca -
Yitzchak Gale