--with-editline fails to find editline/readline.h on FreeBSD

[GoogleCodeExporter]

This is not a big issue, but I think it's better be fixed upstream, using 
autotools.

FreeBSD has editline headers under /usr/include/edit, which is confirmed by 
pure-readline. But Pure interpreter itself does not honor that.

configure:5417: checking editline/readline.h usability
configure:5417: gcc46 -c -O3  -DNDEBUG -DDEBUG=0 -I/usr/local/include 
conftest.c >&5
conftest.c:65:31: fatal error: editline/readline.h: No such file or directory
compilation terminated.

Original issue reported on code.google.com by lich...@gmail.com on 21 Oct 2011 at 1:16

[GoogleCodeExporter]

Well, the standalone libedit at http://www.thrysoee.dk/editline/ indeed uses 
editline/readline.h. But I can add a configure check for edit/readline.h, no 
problem.

Original comment by aggraef@gmail.com on 21 Oct 2011 at 7:50

• Changed state: Accepted

[GoogleCodeExporter]

This issue was closed by revision df2a05400431.

Original comment by aggraef@gmail.com on 21 Oct 2011 at 8:07

• Changed state: Fixed

[GoogleCodeExporter]

Ok, I hope that this fixes it. I'm not sure what to do with pure-readline, 
however, as it doesn't use autoconf. So you'll probably have to stick to a 
source patch there.

Original comment by aggraef@gmail.com on 21 Oct 2011 at 8:10

[GoogleCodeExporter]

pure-readline works out of box. Not sure whether it supports libedit out of
freebsd :-)

Original comment by lich...@gmail.com on 21 Oct 2011 at 8:18

[GoogleCodeExporter]

Well, it has the same "wrong" include of editline/readline.h, but that's not 
enabled unless you set READLINE = edit in the Makefile. Otherwise it picks up 
readline/readline.h and readline/history.h and links against libreadline. So I 
suppose that GNU readline is available on FreeBSD?

Anyway, if there's a choice between libedit and GNU readline on FreeBSD, then I 
think that it's preferable to link both the Pure interpreter and pure-readline 
against the latter (unless that's undesirable for license reasons). GNU 
readline fully supports Unicode, while libedit doesn't (at least when I checked 
last time).

Original comment by aggraef@gmail.com on 21 Oct 2011 at 9:07

[GoogleCodeExporter]

I set READLINE= edit, and the Makefile set -I/usr/include/edit in such case,
which is the preferred way to use libedit on FreeBSD.

GNU readline is available in the base system, but I want to give user a
choice to build a libedit version of pure/pure-readline.

Original comment by lich...@gmail.com on 21 Oct 2011 at 9:57

[GoogleCodeExporter]

Oh... I just checked your last commit. No... I should make it more clear.
The header files are under /usr/include/edit/readline/. A fix on C(PP)FLAGS
may not work, because we need to ensure the libedit version of
readline/readline.h is included.

And now I understand why pure-readline works. First, I passed the
-I/usr/include/edit by accident, and the READLINE=edit is only passed to
Makefile, but CFLAGS is changed at the same time...

So we need to decide:

1. To include <readline/readline.h> with -I/usr/include/edit

or

2. To include <edit/readline/readline.h> with autotools.

Original comment by lich...@gmail.com on 21 Oct 2011 at 10:13

[GoogleCodeExporter]

Hm, that seems to be a different libedit than the one I'm using for testing 
over here (http://www.thrysoee.dk/editline/).

What libedit on FreeBSD are we talking about exactly? I found this one in the 
FreeBSD ports: http://www.freebsd.org/cgi/cvsweb.cgi/ports/devel/libedit/. But, 
taking a look at the pkg-plist of this port, it seems to install readline.h and 
history.h into the include/editline directory, not include/edit/readline. So 
this doesn't seem to be the libedit that you're using, either.

Anyway, the fix that I committed is wrong, so I backed it out again in rev. 
5b42cef59da1 and reopened the issue.

Since I can't test on FreeBSD myself, I either need a working patch or more 
information. Specifically, in order to properly support any kind of GNU 
readline replacement, Pure's configure needs to be able to find the correct 
header files and the correct library. So which header files exactly does your 
include/edit/readline directory contain? Does it also have the history.h file? 
And which library exactly needs to be linked in?

Original comment by aggraef@gmail.com on 22 Oct 2011 at 3:23

• Changed state: Started

[GoogleCodeExporter]

I'm talking about the libedit in the base system. Any ports are installed
under the prefix /usr/local, and the base system is under /usr. Most of the
time, we uses the tools/libs from the base system. The duplicated versions
in the ports are there for more features/higher versions. There is no need
to support them.

Yes. Both
/usr/include/edit/readline/readline.h
and
/usr/include/edit/readline/history.h

And the lib is just /usr/lib/libedit.so, which is found by -ledit

Original comment by lich...@gmail.com on 22 Oct 2011 at 7:10

[GoogleCodeExporter]

Ok, thanks for the info. I made a second attempt in rev. 131edcf1cf32. Please 
give this a try and let me know whether it works for you now. (Note that if you 
have both readline and editline installed on the build system then you'll have 
to add --without-readline --with-editline to the configure line, since 
configure will prefer readline if it is detected.)

Concerning pure-readline, if it works for you as is, then we'll just leave it 
at that. :)

Original comment by aggraef@gmail.com on 22 Oct 2011 at 10:43

• Changed state: Fixed

[GoogleCodeExporter]

Oh, and maybe attach the config.log for your build so that I can double check 
that everything was detected correctly.

Original comment by aggraef@gmail.com on 22 Oct 2011 at 10:46

[GoogleCodeExporter]

Looks good. And the compilation is successful.

configure:5362: checking for a readline compatible library
configure:5394: gcc -o conftest -g -O2  -I/usr/local/include  conftest.c
-liconv -lm -lmpfr -lgmp  -L/usr/local/lib -lgmp -ledit >&5
configure:5394: $? = 0
configure:5412: result: -ledit
configure:5425: checking readline/readline.h usability
configure:5425: gcc -c -g -O2  -I/usr/local/include conftest.c >&5
configure:5425: $? = 0
configure:5425: result: yes
configure:5425: checking readline/readline.h presence
configure:5425: gcc -E  -I/usr/local/include conftest.c
configure:5425: $? = 0
configure:5425: result: yes
configure:5425: checking for readline/readline.h
configure:5425: result: yes
configure:5425: checking edit/readline/readline.h usability
configure:5425: gcc -c -g -O2  -I/usr/local/include conftest.c >&5
configure:5425: $? = 0
configure:5425: result: yes
configure:5425: checking edit/readline/readline.h presence
configure:5425: gcc -E  -I/usr/local/include conftest.c
configure:5425: $? = 0
configure:5425: result: yes
configure:5425: checking for edit/readline/readline.h
configure:5425: result: yes
configure:5425: checking editline/readline.h usability
configure:5425: gcc -c -g -O2  -I/usr/local/include conftest.c >&5
conftest.c:66:31: error: editline/readline.h: No such file or directory

Original comment by lich...@gmail.com on 22 Oct 2011 at 10:56

[GoogleCodeExporter]

Can you please attach the complete generated Makefile and config.h, please? I'd 
like to check which settings it ends up with.

Original comment by aggraef@gmail.com on 22 Oct 2011 at 12:47

[GoogleCodeExporter]

Original comment by lich...@gmail.com on 22 Oct 2011 at 1:43

Attachments:

• config.h
• Makefile

[GoogleCodeExporter]

Thanks. Looks good to me. So I consider this issue fixed.

Original comment by aggraef@gmail.com on 22 Oct 2011 at 2:56

• Changed state: Verified

[GoogleCodeExporter]

The compilation is OK, but I found a potential problem: since readline and
editline are available at the same time, both of their header files are
found. So actually, GNU readline's are always included. However, since the
two versions' headers are almost compatible, the compilation is fine. But to
restrict the headers with --with(out)-editline/readline should be better.

Original comment by lich...@gmail.com on 23 Oct 2011 at 5:07

[GoogleCodeExporter]

Yes, I'm aware of that. But it's hard to be sure which set of headers is the 
right one since the user may employ CPPFLAGS to point configure to any set of 
readline-compatible headers that he might wish to use. So if you're bothered by 
this, in your special case I would just add -I/usr/include/edit to the CPPFLAGS.

But note that Pure uses only a basic subset of readline's API which should be 
available in any drop-in replacement, so there shouldn't actually be a problem. 
AFAICT, the only relevant aspect where readline emulations differ is whether 
add_history is available, and configure reliably detects that no matter which 
set of headers is being used.

Original comment by aggraef@gmail.com on 23 Oct 2011 at 6:19