Integrating editline with ghc
Hi all, I have managed to build ghc using the initial release of the editline package: Hackage link: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/editline-0.1 Haddock: http://code.haskell.org/editline/dist/doc/html/editline/ As I've mentioned before, there are two independent modules: - System.Console.Editline is a very basic (and experimental) interface to the native editline APIs. - System.Console.Editline.Readline contains the readline APIs provided by the editline library (mostly a cut/paste of System.Console.Readline). Currently I'm using just the latter as a drop-in replacement for System.Console.Readline in ghci. I have added a --with-editline flag to ghc's configure script, which has no effect if it's not specified, and otherwise does the following: - Throw an error (at configure time) if editline isn't present (as $hardtop/libraries/editline) - Use the editline package instead of readline when building ghc stage 2 - Use CPP to make InteractiveUI.hs (the main ghci loop) import System.Console.Editline.Readline instead of System.Console.Readline. Does that sound like the right way to handle this? If so, I'll send a darcs patch. Also, should editline be made a boot-package or an extra-package (or neither)? Thanks, -Judah
Judah Jacobson:
Hackage link: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/editline-0.1 Haddock: http://code.haskell.org/editline/dist/doc/html/editline/
As I've mentioned before, there are two independent modules: - System.Console.Editline is a very basic (and experimental) interface to the native editline APIs. - System.Console.Editline.Readline contains the readline APIs provided by the editline library (mostly a cut/paste of System.Console.Readline).
Currently I'm using just the latter as a drop-in replacement for System.Console.Readline in ghci. I have added a --with-editline flag to ghc's configure script, which has no effect if it's not specified, and otherwise does the following:
- Throw an error (at configure time) if editline isn't present (as $hardtop/libraries/editline) - Use the editline package instead of readline when building ghc stage 2 - Use CPP to make InteractiveUI.hs (the main ghci loop) import System.Console.Editline.Readline instead of System.Console.Readline.
Does that sound like the right way to handle this? If so, I'll send a darcs patch.
Sounds good to me.
Also, should editline be made a boot-package or an extra-package (or neither)?
Given that we like this to be the default on some platforms, I believe it belongs into boot-packages (just like readline). Manuel
Judah Jacobson wrote:
- System.Console.Editline.Readline contains the readline APIs provided by the editline library (mostly a cut/paste of System.Console.Readline).
I would like to see a restructuring of the old readline package: 1. a _new_ readline package that only contains the interface that can be implemented using libeditline _or_ libreadline. If this package is call "readline" (with a new version number) most libraries i.e. like Shellac would not need modifications. 2. Two further packages for extension of editline and those functions of readline that are not part of "1". Maybe call these packages editline-ext and readline-ext The extended packages "2" could go under extra libs or hackageDB, while "1" remains a boot package for ghc that can link to editline on macs and readline under linux, but has the same interface and package name! Cheers Christian
Christian Maeder wrote:
The extended packages "2" could go under extra libs or hackageDB, while "1" remains a boot package for ghc that can link to editline on macs and readline under linux, but has the same interface and package name!
I would hope that ghc will link to editline-ext on all platforms. That gives ghc the functionality it needs without getting into legal trouble with the license. Then those who want the full readline interface can install readline-ext, and those who want the full editline interface can install editline. -Yitz
Yitzchak Gale wrote:
Christian Maeder wrote:
The extended packages "2" could go under extra libs or hackageDB, while "1" remains a boot package for ghc that can link to editline on macs and readline under linux, but has the same interface and package name!
I would hope that ghc will link to editline-ext on all platforms. That gives ghc the functionality it needs without getting into legal trouble with the license. Then those who want the full readline interface can install readline-ext, and those who want the full editline interface can install editline.
GHC is in no legal trouble whatsoever... only if proprietary Haskell code uses the readline library and doesn't switch to using the editline backend. On Linux here I have readline installed and not editline currently, so it seems silly to require installing editline by default ("default" meaning "if I don't want to, I have to figure out the right configure flag to give to allow readline to be used"). It makes sense to use editline by default for Mac and Windows builds though, where readline isn't native, I guess. Statically linking to editline for binary builds would be alright (not exporting any readline to ghc-compiled programs by default?). How is "Search for editline first; if not found, try to use readline"? ~Isaac
Isaac Dupree wrote:
GHC is in no legal trouble whatsoever... only if proprietary Haskell code uses the readline library and doesn't switch to using the editline backend.
Agreed. I didn't mean that GHC itself was ever in any legal trouble. But as a compiler, it must be possible for users to compile with it without getting into legal trouble.
On Linux here I have readline installed and not editline currently, so it seems silly to require installing editline by default ("default" meaning "if I don't want to, I have to figure out the right configure flag to give to allow readline to be used"). It makes sense to use editline by default for Mac and Windows builds though, where readline isn't native, I guess. Statically linking to editline for binary builds would be alright (not exporting any readline to ghc-compiled programs by default?). How is "Search for editline first; if not found, try to use readline"?
Yes, I also have a Debian box, and I agree. Regards, Yitz
Yitzchak Gale wrote:
Isaac Dupree wrote:
GHC is in no legal trouble whatsoever... only if proprietary Haskell code uses the readline library and doesn't switch to using the editline backend.
Agreed. I didn't mean that GHC itself was ever in any legal trouble. But as a compiler, it must be possible for users to compile with it without getting into legal trouble.
Yes. I'm still learning Haskell, and it's my intention to use GHC to produce commercial plugins for an application on Windows (and possibly OS X, haven't decided yet). This whole discussion makes me worry - not because I have any intention to break any licences, but because I might do so by accident. At this point in my learning, I've got no idea what will cause "problem packages" (problems from my point of view being ones that cause a phone call to a lawyer) to be linked in to my binaries. It would be enormously helpful if there was a wiki page somewhere that said "To use GHC/mingw as a compiler for commercial software, it's likely you want to avoid these modules and command-line flags" or alternatively "To guarantee that no LGPL or GPL libraries are linked, use these flags". The last thing I want is to cause myself extra work when someone chucks my plugin through a hex editor, sees a whole load of GMP symbols (for example) and demands some form of compliance that commercially I'd rather avoid. -- Alex
Alex Young:
Yitzchak Gale wrote:
Isaac Dupree wrote:
GHC is in no legal trouble whatsoever... only if proprietary Haskell code uses the readline library and doesn't switch to using the editline backend. Agreed. I didn't mean that GHC itself was ever in any legal trouble. But as a compiler, it must be possible for users to compile with it without getting into legal trouble.
Yes. I'm still learning Haskell, and it's my intention to use GHC to produce commercial plugins for an application on Windows (and possibly OS X, haven't decided yet). This whole discussion makes me worry - not because I have any intention to break any licences, but because I might do so by accident. At this point in my learning, I've got no idea what will cause "problem packages" (problems from my point of view being ones that cause a phone call to a lawyer) to be linked in to my binaries. It would be enormously helpful if there was a wiki page somewhere that said "To use GHC/mingw as a compiler for commercial software, it's likely you want to avoid these modules and command-line flags" or alternatively "To guarantee that no LGPL or GPL libraries are linked, use these flags".
The last thing I want is to cause myself extra work when someone chucks my plugin through a hex editor, sees a whole load of GMP symbols (for example) and demands some form of compliance that commercially I'd rather avoid.
The Haskell package system Cabal has a package description format that includes an entry stating the packages license. You can browse packages at http://hackage.haskell.org/packages/hackage.html and the package entries include the license field. For example, the entry for readline http://hackage.haskell.org/cgi-bin/hackage-scripts/package/readline-1.0.1.0 says it is GPL'ed - ie, you may not link it into proprietary code. I agree that a wiki page explaining this and the situation with static versus dynamic linking of LGPL'ed code would be helpful. Manuel
Yitzchak Gale wrote:
Christian Maeder wrote:
The extended packages "2" could go under extra libs or hackageDB, while "1" remains a boot package for ghc that can link to editline on macs and readline under linux, but has the same interface and package name!
I would hope that ghc will link to editline-ext on all platforms. That gives ghc the functionality it needs without getting into legal trouble with the license. Then those who want the full readline interface can install readline-ext, and those who want the full editline interface can install editline.
Just to clarify: ghc will link to "libedit" if it is available on your platform, but the Haskell package will still have the name "readline" and give ghc all the functionality it needs (without licence problems). Only the current readline Haskell package needs "libreadline" and supplies more functionality than needed by ghc. This extra-functionality should go into a new Haskell package readline-ext (that will only be rarely needed). The haskell package "editline-ext" is just an add-on that _requires_ "libedit" (an is only needed for special future developments). Also editline-ext should only be used rarely, because some installation will still only have "libreadline". The new haskell package "readline" will only contain the common functionality of libedit and libreadline! The new haskell package "readline" should not be renamed in order to achieve best backward compatibility in most cases. Renaming it (i.e. to "editline") would not change the possibility to either link to libedit _or_ libreadline (but would require to change all packages that currently use readline) Christian
Christian Maeder wrote:
ghc will link to "libedit" if it is available on your platform, but the Haskell package will still have the name "readline" and give ghc all the functionality it needs (without licence problems). Only the current readline Haskell package needs "libreadline" and supplies more functionality than needed by ghc. This extra-functionality should go into a new Haskell package readline-ext (that will only be rarely needed).
That is one possible solution for GHC. The problem is that the readline package currently provides System.Console.Readline with the full interface to readline. It has been that way for eons, so we must assume that there is software out there that uses all of it, even though ghc only uses part of it. We don't want to break those programs, and that includes creating a situation where the programs will no longer compile unless the user installs some new package with a different name. So I think the package named "readline" needs to continue to provide both the interface and the implementation for full readline. However, if needed, it can provide some or all of the pieces vacuously by simply depending on some new packages. On the other hand, GHC should depend only on a subset of readline that can optionally be provided by editline instead. And in fact, editline should be preferred over readline when available. There should be a smooth upgrade path to the new system for all users, both of GHC and the readline, for any combination of versions installed of any of those things. Everything should happen automatically as people gradually upgrade GHC and/or various readline-like packages to new versions. Can we meet all of those goals? Thanks, Yitz
On Jan 17, 2008 6:00 AM, Christian Maeder
Yitzchak Gale wrote:
Christian Maeder wrote:
The extended packages "2" could go under extra libs or hackageDB, while "1" remains a boot package for ghc that can link to editline on macs and readline under linux, but has the same interface and package name!
I would hope that ghc will link to editline-ext on all platforms. That gives ghc the functionality it needs without getting into legal trouble with the license. Then those who want the full readline interface can install readline-ext, and those who want the full editline interface can install editline.
Just to clarify:
ghc will link to "libedit" if it is available on your platform, but the Haskell package will still have the name "readline" and give ghc all the functionality it needs (without licence problems).
Only the current readline Haskell package needs "libreadline" and supplies more functionality than needed by ghc. This extra-functionality should go into a new Haskell package readline-ext (that will only be rarely needed).
The haskell package "editline-ext" is just an add-on that _requires_ "libedit" (an is only needed for special future developments).
Also editline-ext should only be used rarely, because some installation will still only have "libreadline".
The new haskell package "readline" will only contain the common functionality of libedit and libreadline!
The new haskell package "readline" should not be renamed in order to achieve best backward compatibility in most cases. Renaming it (i.e. to "editline") would not change the possibility to either link to libedit _or_ libreadline (but would require to change all packages that currently use readline)
This sounds fine, except I don't think that we should have a package editline-ext. A readline API is either in both libedit and libreadline (in which case it should be in the readline package), or it is only in libreadline (in which case it should be in readline-ext). The functions in System.Console.Editline are unrelated to the readline APIs; I think that they should just go in a package called "editline". -Judah
On Jan 17, 2008 2:08 PM, Yitzchak Gale wrote:
I would hope that ghc will link to editline-ext on all platforms.
Unfortunately it seems that editline cannot currently be build on Windows. I have tried to build the editline source from http://www.thrysoee.dk/editline/ with MinGW/msys. Pdcurses could be used instead of ncurses, but it also requires termios.h which MinGW does not have.
Christian Maeder:
Judah Jacobson wrote:
- System.Console.Editline.Readline contains the readline APIs provided by the editline library (mostly a cut/paste of System.Console.Readline).
I would like to see a restructuring of the old readline package:
1. a _new_ readline package that only contains the interface that can be implemented using libeditline _or_ libreadline. If this package is call "readline" (with a new version number) most libraries i.e. like Shellac would not need modifications.
I disagree. Readline should stay as it is. (Why force existing readline users who use functionality not supported by editline's emulation layer to change the package they are using?) Instead, we should have a new module whose interface coincides with editline's readline emulation. Everybody who wants to use editline when available and readline only if editline is not available can then use that new module (which I called EditReadline in my previous post). GHC will be one of these programs. Manuel
Manuel M T Chakravarty wrote:
Christian Maeder:
1. a _new_ readline package that only contains the interface that can be implemented using libeditline _or_ libreadline. If this package is call "readline" (with a new version number) most libraries i.e. like Shellac would not need modifications.
I disagree. Readline should stay as it is. (Why force existing readline users who use functionality not supported by editline's emulation layer to change the package they are using?)
Your point is also supported by Yitz Gale, my point by Malcolm. Where are the users that use the functionality not supported by editline's emulation layer? (Shout now or be quiet ever after) Disadvantage of my proposal (to change the readline interface): We have restructured libraries massively between 6.2 and 6.8 (why not for 6.10?) Disadvantage of making a new interface: Everybody who wants to profit from libedit has to do active changes (so many will not bother, although most would want it.) Christian
Christian Maeder:
Manuel M T Chakravarty wrote:
Christian Maeder:
1. a _new_ readline package that only contains the interface that can be implemented using libeditline _or_ libreadline. If this package is call "readline" (with a new version number) most libraries i.e. like Shellac would not need modifications.
I disagree. Readline should stay as it is. (Why force existing readline users who use functionality not supported by editline's emulation layer to change the package they are using?)
Your point is also supported by Yitz Gale, my point by Malcolm.
Where are the users that use the functionality not supported by editline's emulation layer? (Shout now or be quiet ever after)
Are you seriously suggesting that we mess up users who do not read the various mailing lists constantly to defend the APIs they are using? Manuel
Manuel M T Chakravarty wrote:
Christian Maeder:
Manuel M T Chakravarty wrote:
Christian Maeder:
1. a _new_ readline package that only contains the interface that can be implemented using libeditline _or_ libreadline. If this package is call "readline" (with a new version number) most libraries i.e. like Shellac would not need modifications.
I disagree. Readline should stay as it is. (Why force existing readline users who use functionality not supported by editline's emulation layer to change the package they are using?)
Your point is also supported by Yitz Gale, my point by Malcolm.
Where are the users that use the functionality not supported by editline's emulation layer? (Shout now or be quiet ever after)
Are you seriously suggesting that we mess up users who do not read the various mailing lists constantly to defend the APIs they are using?
I only wanted to find out which user group would need to change readline to editline and (if following my suggestion) which group readline to GPL-readline in cabal files, and which of the two user groups is bigger. Since it's not clear yet, what portion of readline can be emulated by editline this is difficult to estimate. Christian
Christian Maeder wrote:
Where are the users that use the functionality not supported by editline's emulation layer? (Shout now or be quiet ever after)
I only wanted to find out which user group would need to change readline to editline and (if following my suggestion) which group readline to GPL-readline in cabal files, and which of the two user groups is bigger.
Since it's not clear yet, what portion of readline can be emulated by editline this is difficult to estimate.
It is always impossible to estimate this, because users are not required to register anyplace, and they are not required to read this or any other discussion list. We should not cause people's programs to break silently by changing a fundamental API, unless there is no alternative. In this case there is a reasonable alternative. Anyone who wants to change over to editline - native or readline-compatible - can easily do so, at their leisure. Anyone who wants things to stay the way they are can do nothing. Do you see any problem with that approach? I think that in most cases, people are happy with readline and will not need to change. Nevertheless, making editline available in this way is critically important, because certain projects are difficult or impossible without it. And of course, it's a great improvement for the Mac platform. So your work on this is highly appreciated. Thanks, Yitz
Yitzchak Gale wrote:
We should not cause people's programs to break silently by changing a fundamental API, unless there is no alternative. In this case there is a reasonable alternative. Anyone who wants to change over to editline - native or readline-compatible - can easily do so, at their leisure. Anyone who wants things to stay the way they are can do nothing.
1. Things don't break silently (I hope), they break during compilation. 2. With every new ghc major version (or library version) there is a list of user visible changes. 3. if ghci is going to use editline (at least on Macs by default) then readline would not need to be a core package und users might need to install package readline explicitely. (Then at least everybody using readline has to do something manually, at least users on Macs who complain most if something does not run out of the box.)
Do you see any problem with that approach?
No, I've only pointed out the alternative, I hope. I don't know what fits the needs of the majority most. Let's vote? Christian
Christian Maeder wrote:
3. if ghci is going to use editline... then readline would not need to be a core package und users might need to install package readline explicitly.
OK, I get it. Even if we leave readline as it is, so that the package system will theoretically not force the person to take action, in practice action will be needed the next time the person upgrades GHC. So you would like to minimize overall work of changing packages over all users. Even so, I think it is more important to minimize confusion over users who are not aware of this whole discussion, and may have minimal knowledge of the package system. They don't want to have to figure things out - they just want it to keep working as before. The need to re-install some package due to the shrinking GHC library core is an annoyance all GHC users are aware of by now. You figure out what has disappeared, and you install it. Changing the semantics of the readline package would add to the confusion, I believe. Also, I think in general we should do what makes the most sense within the package system itself. GHC library core shrinkage is an external issue, though I agree that in practice it will affect everyone. So I am still in favor of keeping readline as it is. Thanks, Yitz
On Jan 17, 2008 1:19 AM, Christian Maeder
Judah Jacobson wrote:
- System.Console.Editline.Readline contains the readline APIs provided by the editline library (mostly a cut/paste of System.Console.Readline).
I would like to see a restructuring of the old readline package:
1. a _new_ readline package that only contains the interface that can be implemented using libeditline _or_ libreadline. If this package is call "readline" (with a new version number) most libraries i.e. like Shellac would not need modifications.
2. Two further packages for extension of editline and those functions of readline that are not part of "1". Maybe call these packages editline-ext and readline-ext
A problem with the above proposal: the readline-ext package would depend not just on the readline package, but on an instance of the readline package that was built against libreadline specifically. I don't think that we can enforce that constraint; and even if we could, on a machine with both editline and readline installed it would get confusing pretty quickly. I think it will be much simpler if we keep the readline and editline packages as they are now, and possibly add a third readline-compat package which can use either one as a dependency. Then any project (including GHC) can choose which of those packages to use, based on API requirements and/or license issues. Best, -Judah
Judah Jacobson wrote:
I think it will be much simpler if we keep the readline and editline packages as they are now, and possibly add a third readline-compat package which can use either one as a dependency. Then any project (including GHC) can choose which of those packages to use, based on API requirements and/or license issues.
Could then editline go already into ghc-6.8.3, because interfaces don't change? Re-iterating, I would like to see your package readline-compat and hope it will be sufficient for the packages Shellac and Shellac-readline. (Even better if the current package readline is renamed to old-readline and readline-compat to readline.) I wonder how many hackage packages have readline as build-depends (and how many of them would be content with readline-compat). Which version of editline to you require? Our newest version installed (under Solaris) is: editline.h,v 1.5 Which include files are used on Macs? Cheers Christian
Yitzchak Gale wrote:
Hi Christian,
Christian Maeder wrote:
...Even better if the current package readline is renamed to old-readline and readline-compat to readline.
I have been trying to understand why you want to do that. What would we gain?
On Macs I want Shellac-readline to use editline, under linux we don't have editline, so there I want to continue to use Shellac-readline as it is now. But I don't want to use different Haskell packages for different platforms (for the same project). On Macs, the only change I had to make to the Shellac-readline package was to replace "readline >= 1.0" with "editline >= 0.1" in Shellac-readline.cabal and "System.Console.Readline" with "System.Console.Editline.Readline" in src/System/Console/Shell/Backend/Readline.hs These changes were not necessary if readline-compat supplied a module System.Console.Readline and would be named "readline". (A better name for old-readline would be GPL-readline, though) I wonder how many other packages would work without changes and how many would break, because readline-compat supplies only a part of the old readline. Depending on what the ghc team and the library maintainers decide, either "readline" has to be changed to "readline-compat" in *.cabal or (worse) we get packages Shellac-readline and Shellac-editline or (more worse) Shellac-readline stays as is and I have to fiddle with editline or readline on Macs myself (like now). HTH Christian
Christian Maeder wrote:
Depending on what the ghc team and the library maintainers decide, "readline" has to be changed to "readline-compat" in *.cabal
Maybe someone could point out how the conditional build-depends entry would look like in Shellac-readline.cabal if readline is to be used for older ghc versions (with GNU readline only) and readline-compat for newer ghcs (possible using editline). Will there be a new flag hasReadlineCompat? Cheers C.
Christian Maeder wrote:
Depending on what the ghc team and the library maintainers decide, either "readline" has to be changed to "readline-compat" in *.cabal or (worse) we get packages Shellac-readline and Shellac-editline or (more worse) Shellac-readline stays as is and I have to fiddle with editline or readline on Macs myself (like now).
It would be a bad idea to remove functionality from the readline package. It's a binding to the GNU readline library, and as such it does a fine job. In a similar vein, we should have an editline package that provides a binding to libedit. For convenience, we would like there to be an API that can be supported by both readline and editline. It would be a bad idea for this to be a package, because (as I mentioned earlier on libraries@) that package would have a variant license, depending on whether the API-provider was readline or editline at build-time (or perhaps in the future link-time or run-time). If you chose between readline and editline, then you have to make an explicit choice in your .cabal file - making a package that abstracts this choice is not good, unless said package is explicitly GPL'd. So the compatible API could be in a module that is exposed by *both* readline and editline, say System.Console.ReadlineCompat. So your source code wouldn't have to change to switch from one to the other, just your .cabal file. Cheers, Simon
Simon Marlow wrote:
It would be a bad idea to remove functionality from the readline package. It's a binding to the GNU readline library, and as such it does a fine job.
I only want to move (not remove).
For convenience, we would like there to be an API that can be supported by both readline and editline. It would be a bad idea for this to be a package, because (as I mentioned earlier on libraries@) that package would have a variant license, depending on whether the API-provider was readline or editline at build-time (or perhaps in the future link-time or run-time). If you chose between readline and editline, then you have to make an explicit choice in your .cabal file - making a package that abstracts this choice is not good, unless said package is explicitly GPL'd.
Actually, the license is not (so) important for me. I basically want the convenience to link against libedit on Macs and against libreadline on other unix system, because these libs are usually there without further ado.
So the compatible API could be in a module that is exposed by *both* readline and editline, say System.Console.ReadlineCompat. So your source code wouldn't have to change to switch from one to the other, just your .cabal file.
Things ghc does not support, users have to do. Christian
Christian Maeder wrote:
Simon Marlow wrote:
It would be a bad idea to remove functionality from the readline package. It's a binding to the GNU readline library, and as such it does a fine job.
I only want to move (not remove).
I don't think it's necessary to remove (or move) anything from readline at all. That would break clients unnecessarily. By all means add a new module that exports the lowest-common-denominator API.
For convenience, we would like there to be an API that can be supported by both readline and editline. It would be a bad idea for this to be a package, because (as I mentioned earlier on libraries@) that package would have a variant license, depending on whether the API-provider was readline or editline at build-time (or perhaps in the future link-time or run-time). If you chose between readline and editline, then you have to make an explicit choice in your .cabal file - making a package that abstracts this choice is not good, unless said package is explicitly GPL'd.
Actually, the license is not (so) important for me. I basically want the convenience to link against libedit on Macs and against libreadline on other unix system, because these libs are usually there without further ado.
But other people really do care about licenses, and it's vitally important that each package has a clearly-defined license. Under my proposal you would be able to do exactly what you want. The difference is that you can't hide the choice between libedit and libreadline in a package of its own, unless that package is GPL.
So the compatible API could be in a module that is exposed by *both* readline and editline, say System.Console.ReadlineCompat. So your source code wouldn't have to change to switch from one to the other, just your .cabal file.
Things ghc does not support, users have to do.
This isn't about GHC, it's about the readline/editline packages! Cheers, Simon
On Jan 21, 2008 2:40 AM, Christian Maeder
Judah Jacobson wrote:
I think it will be much simpler if we keep the readline and editline packages as they are now, and possibly add a third readline-compat package which can use either one as a dependency. Then any project (including GHC) can choose which of those packages to use, based on API requirements and/or license issues.
Could then editline go already into ghc-6.8.3, because interfaces don't change?
Re-iterating, I would like to see your package readline-compat and hope it will be sufficient for the packages Shellac and Shellac-readline. (Even better if the current package readline is renamed to old-readline and readline-compat to readline.)
Hmm...As Christian suggested to me in a private email, I was wrong in my initial testing of Shellac-readline: it relies on a variable (_history_max_entries) that is not in editline. So I think we should definitely keep the readline package the way that it is. Luckily, there are other functions, giving the same functionality, which are shared by readline and editline, and are scheduled to become official parts of readline in a week or two; see (http://www.nabble.com/Readline-read_history-and-write_history-addition-td149...) I'll add those functions to the editline and readline-compat packages.
I wonder how many hackage packages have readline as build-depends (and how many of them would be content with readline-compat).
Which version of editline to you require?
Our newest version installed (under Solaris) is: editline.h,v 1.5
Which include files are used on Macs?
On OS X 10.4, I have readline.h,v 1.11 as the libedit readline compatibility header. Can you please try linking a simple program that uses System.Console.Editline.Readline on your Solaris machine and see if it throws up any link errors? If so, I may be able to fix that. Thanks, -Judah
Judah Jacobson wrote:
On OS X 10.4, I have readline.h,v 1.11 as the libedit readline compatibility header. Can you please try linking a simple program that uses System.Console.Editline.Readline on your Solaris machine and see if it throws up any link errors? If so, I may be able to fix that.
I wasn't able to install your editline-0.1 package under Solaris. Our installed files are: /usr/local/lib/libeditline.so -> libeditline.so.0.0.0 /usr/local/lib/libeditline.so.0 -> libeditline.so.0.0.0 /usr/local/lib/libeditline.so.0.0.0 /usr/local/lib/libeditline.a /usr/local/lib/libeditline.la /usr/local/include/editline.h Christian checking for gcc option to accept ANSI C... none needed checking for tputs in -lncurses... yes checking for el_init in -ledit... no checking for readline in -ledit... no checking how to run the C preprocessor... gcc -E checking for egrep... egrep checking for ANSI C header files... no checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking editline/readline.h usability... no checking editline/readline.h presence... no checking for editline/readline.h... no checking readline/readline.h usability... yes checking readline/readline.h presence... yes checking for readline/readline.h... yes configure: error: editline not found, so this package cannot be built
participants (8)
-
Alex Young -
Christian Maeder -
Felix Martini -
Isaac Dupree -
Judah Jacobson -
Manuel M T Chakravarty -
Simon Marlow -
Yitzchak Gale