Martin Panter added the comment: Quoting Ned: “The current behavior is: enable building readline with GNU readline if found on the search paths, . . . and, if not found and on OS X, use editline if found on the search paths. Some build scripts depend on that behavior.”
Can you point out any logic (e.g. in configure.ac) that handles this? I suspect you might be mistaken. My understanding is that we always include <readline/readline.h> and always link against -lreadline, regardless of platform. My guess is that on OS X, the include file and library are actually pointers to Editline code, rather than Gnu code. This is in contrast to my situation on Arch Linux, where I can install both the Gnu “readline” and the “libedit” packages without conflict. Gnu Readline is accessible via <readline/readline.h> and -lreadline, and Editline’s Readline compatibility is accessible via <editline/readline.h> and -ledit. So I suspect there is no special on-OS-X condition to change or remove (if we ignore those #ifdef __APPLE__ bug workarounds for the moment). Maybe I should drop that DEFAULT_LIBREADLINE business from the patch. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue13501> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
