Bruno Haible <[EMAIL PROTECTED]> writes: >> > HAVE_READLINE vs. HAVE_READLINE_READLINE_H should be the same. >> >> I solved it slightly differently. I made these two tests orthogonal. >> readline/readline.h is used by the header file if available. >> -lreadline is used instead of the *.c file if available. The two >> decisions don't depend on each other. > > Hmm. That means that when the library is misinstalled but the > <readline/readline.h> include file exists, gnulib's readline.h will include > it.
Yes. > For the prototype of the declared function it doesn't matter, since > the compilation of lib/readline.c will verify whether it's the > same. Exactly. > But if a program uses other functions like rl_set_prompt() or > rl_initialize() the code will compile fine but yield a link > error. Sounds a little dangerous. But maybe it's fine since in this > case the problem is really with the guy's system? If the program use rl_set_prompt etc, it won't build if the system doesn't have libreadline at all. So then what is the point of using the module? The comment in the source file says the module isn't for applications that use rl_set_prompt or other stuff. IMHO, a program that use this module shouldn't even condition use of rl_set_prompt etc on HAVE_READLINE. That create an assumption on how this module was implemented that isn't future proof. Either a program use this module and ONLY call readline, or it should require the real libreadline. >> > IMO, support for FreeBSD libedit [1] can be added at a later date. Not >> > urgent. >> >> Interesting. I wonder if the gnulib module really should have another >> name. E.g., gl_prompt. > > gl_readline is OK. With this name, everyone will know immediately what it's > about. It was just a thought, I'm fine with the current name. Thanks. _______________________________________________ bug-gnulib mailing list bug-gnulib@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnulib
