Re: darcs patch: [PROOF OF CONCEPT] build readline package with libedit
Robert Dockins wrote:
I've now built a Shellac-editline package using the bindings from the editline-0.2. It's on hackage[1]. I've run the package through a quick sanity check, but I have not extensively tested it.
Thanks, I've compiled it and run a short test on an Intel Leopard with success.
[1]http://hackage.haskell.org/cgi-bin/hackage-scripts/package/Shellac-editline-...
I wasn't amused to also change my sources to use editlineBackend instead of readlineBackend, besides changing the import to System.Console.Shell.Backend.Editline. Maybe the interfaces of the packages could be identical and one gets a warning when both packages are installed. (I suppose one package must be hidden then, during compilation.) 1. In order to compile under MacOS with editline and under Linux with readline it would be nice to use the same sources. In order to avoid several #ifdefs (maybe differently or suboptimal given) in user sources (to achieve 1.) such #ifdefs (or wrappers) should be part of the libraries (including the documentation for the license differences)! Cheers Christian
On Tue, 19 Feb 2008, Christian Maeder wrote:
In order to avoid several #ifdefs (maybe differently or suboptimal given) in user sources (to achieve 1.) such #ifdefs (or wrappers) should be part of the libraries (including the documentation for the license differences)!
Can Cabal-1.2's flag capability manage such a task?
On Tue, 2008-02-19 at 12:01 +0100, Henning Thielemann wrote:
On Tue, 19 Feb 2008, Christian Maeder wrote:
In order to avoid several #ifdefs (maybe differently or suboptimal given) in user sources (to achieve 1.) such #ifdefs (or wrappers) should be part of the libraries (including the documentation for the license differences)!
Can Cabal-1.2's flag capability manage such a task?
I don't think I understand the problem clearly enough to say. Perhaps someone can try explaining it in more detail. Duncan
On 19 feb 2008, at 12.31, Duncan Coutts wrote:
On Tue, 2008-02-19 at 12:01 +0100, Henning Thielemann wrote:
On Tue, 19 Feb 2008, Christian Maeder wrote:
In order to avoid several #ifdefs (maybe differently or suboptimal given) in user sources (to achieve 1.) such #ifdefs (or wrappers) should be part of the libraries (including the documentation for the license differences)!
Can Cabal-1.2's flag capability manage such a task?
I don't think I understand the problem clearly enough to say. Perhaps someone can try explaining it in more detail.
I don't think Cabal can help easily here since it works on the module level. It also won't rename modules which would be required in this case, I think. / Thomas
On Tue, 19 Feb 2008, Thomas Schilling wrote:
I don't think Cabal can help easily here since it works on the module level. It also won't rename modules which would be required in this case, I think.
You can separate the differences out in two modules with the same name but different source directories and add a Cabal switch on a flag that chooses between two Hs-Source-Dirs.
Duncan Coutts wrote:
On Tue, 2008-02-19 at 12:01 +0100, Henning Thielemann wrote:
On Tue, 19 Feb 2008, Christian Maeder wrote:
In order to avoid several #ifdefs (maybe differently or suboptimal given) in user sources (to achieve 1.) such #ifdefs (or wrappers) should be part of the libraries (including the documentation for the license differences)! Can Cabal-1.2's flag capability manage such a task?
I don't think I understand the problem clearly enough to say. Perhaps someone can try explaining it in more detail.
Currently, we have packages Shellac-readline and Shellac-editline. with exposed-modules: System.Console.Shell.Backend.Readline resp. exposed-modules: System.Console.Shell.Backend.Editline Each module exports a single constant: Prelude> :browse System.Console.Shell.Backend.Editline editlineBackend :: System.Console.Shell.Backend.ShellBackend () Prelude> :browse System.Console.Shell.Backend.Readline readlineBackend :: System.Console.Shell.Backend.ShellBackend () On Macs I want to use Editline, under Linux Readline, Therefore I #ifdef my sources. (The functionality seems to be the same for both packages) My questions are: 1. Should not the exported constants have the same name 2. Should not even the module name be the same in both packages As long as not both packages are installed the compiler would pick the proper package without my #ifdefs. HTH Christian
On Tuesday 19 February 2008 09:22:34 am Christian Maeder wrote:
Duncan Coutts wrote:
On Tue, 2008-02-19 at 12:01 +0100, Henning Thielemann wrote:
On Tue, 19 Feb 2008, Christian Maeder wrote:
In order to avoid several #ifdefs (maybe differently or suboptimal given) in user sources (to achieve 1.) such #ifdefs (or wrappers) should be part of the libraries (including the documentation for the license differences)!
Can Cabal-1.2's flag capability manage such a task?
I don't think I understand the problem clearly enough to say. Perhaps someone can try explaining it in more detail.
Currently, we have packages Shellac-readline and Shellac-editline. with
exposed-modules: System.Console.Shell.Backend.Readline
resp.
exposed-modules: System.Console.Shell.Backend.Editline
Each module exports a single constant:
Prelude> :browse System.Console.Shell.Backend.Editline editlineBackend :: System.Console.Shell.Backend.ShellBackend () Prelude> :browse System.Console.Shell.Backend.Readline readlineBackend :: System.Console.Shell.Backend.ShellBackend ()
On Macs I want to use Editline, under Linux Readline, Therefore I #ifdef my sources. (The functionality seems to be the same for both packages)
My questions are:
1. Should not the exported constants have the same name 2. Should not even the module name be the same in both packages
I don't think so. I personally view such "top level" overloading as undesirable. There might possibly be a legitimate reason to want both modules avaliable simultaneously. Punning the module name would make that impossible. If you want a package that multiplexes the editline package or the readline package depending on avaliability, that would be easy to do. It would just require wraping up the #ifdef stuff needed into a single place. I can probably find a few minutes this afternoon/evening to do this.
As long as not both packages are installed the compiler would pick the proper package without my #ifdefs.
HTH Christian
Robert Dockins wrote:
If you want a package that multiplexes the editline package or the readline package depending on avaliability, that would be easy to do. It would just require wraping up the #ifdef stuff needed into a single place. I can probably find a few minutes this afternoon/evening to do this.
Yes, that's exactly what I want, although a third module name is needed. How do you set up the cabal file for such a package? The license entry could simply mention the possible readline dependency. Cheers Christian (Maybe that's useful for other packages, too, that can be realized via readline or editline, or even for the common bits of the readline and editline packages, since it's not the module System.Console.Editline.Readline ifself)
On Tuesday 19 February 2008 01:35:51 pm Christian Maeder wrote:
Robert Dockins wrote:
If you want a package that multiplexes the editline package or the readline package depending on avaliability, that would be easy to do. It would just require wraping up the #ifdef stuff needed into a single place. I can probably find a few minutes this afternoon/evening to do this.
Yes, that's exactly what I want, although a third module name is needed.
Ok. Here we go. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/Shellac-compatlin...
How do you set up the cabal file for such a package?
Cabal configuration flags can do this sort of thing.
The license entry could simply mention the possible readline dependency.
Cheers Christian
(Maybe that's useful for other packages, too, that can be realized via readline or editline, or even for the common bits of the readline and editline packages, since it's not the module System.Console.Editline.Readline ifself)
Rob Dockins
Robert Dockins wrote:
http://hackage.haskell.org/cgi-bin/hackage-scripts/package/Shellac-compatlin...
Brilliant, it works as expected. Thanks again.
How do you set up the cabal file for such a package?
Cabal configuration flags can do this sort of thing.
Yes, good to see this.
The license entry could simply mention the possible readline dependency.
We'll see if the license will be a problem. Cheers Christian
I've actually put together a readline-compat package like you described:
http://code.haskell.org/readline-compat
I hadn't put it on hackage yet because I've been waiting for a resolution to
http://hackage.haskell.org/trac/ghc/ticket/2053
-Judah
On Tue, Feb 19, 2008 at 10:35 AM, Christian Maeder
Robert Dockins wrote:
If you want a package that multiplexes the editline package or the readline package depending on avaliability, that would be easy to do. It would just require wraping up the #ifdef stuff needed into a single place. I can probably find a few minutes this afternoon/evening to do this.
Yes, that's exactly what I want, although a third module name is needed. How do you set up the cabal file for such a package?
The license entry could simply mention the possible readline dependency.
Cheers Christian
(Maybe that's useful for other packages, too, that can be realized via readline or editline, or even for the common bits of the readline and editline packages, since it's not the module System.Console.Editline.Readline ifself)
_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries
Judah Jacobson wrote:
I've actually put together a readline-compat package like you described:
This is not the way to go, IMO. As Manuel said, we don't want packages with licenses that depend on the way the package is built. The readline-compat package above has this problem, and the only way to fix it is to make its license GPL. But presumably that's exactly what you don't want to do, because the purpose of using editline is to avoid the GPL. Packages which want to use either editline or readline should say so in their .cabal files, we cannot abstract this choice into a package of its own. Cheers, Simon
Simon Marlow wrote:
Judah Jacobson wrote:
I've actually put together a readline-compat package like you described:
This is not the way to go, IMO. As Manuel said, we don't want packages with licenses that depend on the way the package is built. The readline-compat package above has this problem, and the only way to fix it is to make its license GPL. But presumably that's exactly what you don't want to do, because the purpose of using editline is to avoid the GPL.
My major aim was to avoid that users of our software need to install the GNUReadline.framework (or libreadline) on their macs (although we could probably also link libreadline and libncurses statically.)
Packages which want to use either editline or readline should say so in their .cabal files, we cannot abstract this choice into a package of its own.
You also abstract the choice between windows and unix. Doesn't that have license implications, too? Cheers Christian
Christian Maeder wrote:
Simon Marlow wrote:
Judah Jacobson wrote:
I've actually put together a readline-compat package like you described:
http://code.haskell.org/readline-compat This is not the way to go, IMO. As Manuel said, we don't want packages with licenses that depend on the way the package is built. The readline-compat package above has this problem, and the only way to fix it is to make its license GPL. But presumably that's exactly what you don't want to do, because the purpose of using editline is to avoid the GPL.
My major aim was to avoid that users of our software need to install the GNUReadline.framework (or libreadline) on their macs (although we could probably also link libreadline and libncurses statically.)
As far as I can see, you don't need a package with a variant license in order to do what you want. The package in question just has an option to use editline instead of readline at build-time. If you want to make life even easier, do as was suggested before and add a module with a single compatible API to both editline and readline, so clients can use the same API regardless of which package they link against.
Packages which want to use either editline or readline should say so in their .cabal files, we cannot abstract this choice into a package of its own.
You also abstract the choice between windows and unix. Doesn't that have license implications, too?
I'm not aware of any license implications - what problem specifically are you referring to? Cheers, Simon
Simon Marlow wrote:
As far as I can see, you don't need a package with a variant license in order to do what you want. The package in question just has an option to use editline instead of readline at build-time.
I'm not the license expert. I did not invent a "variant license". GPL seems to be fine for me in all cases.
If you want to make life even easier, do as was suggested before and add a module with a single compatible API to both editline and readline, so clients can use the same API regardless of which package they link against.
Currently, I'm happy with Rob Dockins's Shellac-compatline.
You also abstract the choice between windows and unix. Doesn't that have license implications, too?
I'm not aware of any license implications - what problem specifically are you referring to?
No specific problem. Can I freely link against all the window dlls regarding file access (and thus for the Prelude) of package win32? Cheers Christian
Duncan Coutts:
On Tue, 2008-02-19 at 12:01 +0100, Henning Thielemann wrote:
On Tue, 19 Feb 2008, Christian Maeder wrote:
In order to avoid several #ifdefs (maybe differently or suboptimal given) in user sources (to achieve 1.) such #ifdefs (or wrappers) should be part of the libraries (including the documentation for the license differences)!
Can Cabal-1.2's flag capability manage such a task?
I don't think I understand the problem clearly enough to say. Perhaps someone can try explaining it in more detail.
Maybe I am reading this the wrong way, but didn't we say we DON'T want to build the readline package with libedit, but rather have a separate editline package. A fundamental reason for avoiding building the same library interface with alternatively readline and editline was that the license of that package would then have to change on a build per build basis. I think we concluded that (a) that would be confusing and (b) is not support by Cabal's package meta information. Manuel
participants (8)
-
Christian Maeder -
Duncan Coutts -
Henning Thielemann -
Judah Jacobson -
Manuel M T Chakravarty -
Robert Dockins -
Simon Marlow -
Thomas Schilling