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