Subject: Re: libedit's readline.h now installed in /usr/include/readline/
To: matthew green <mrg@eterna.com.au>
From: Jaromír Dolecek <dolecek@ics.muni.cz>
List: tech-userlevel
Date: 01/06/2001 10:22:31
matthew green wrote:
> this change seems like a really bad idea. what's the point of moving it to
> a <readline/readline.h> if you have to modify every makefile to deal with it?
GNU readline installs to <readline/readline.h>. Most applications
use #include <readline/readline.h>.
Obviously, we should adhere to what readline uses - the whole point of the
emulation layer is to provide an environment where applications
written for readline may be linked with editline with minimal
changes. It was a mistake that the headers were originally installed in
/usr/include and not /usr/include/readline/, at a first place.
Note that this change only breaks those pkgs, which contains special
patches to use NetBSD-specific <readline.h> instead of 'standard'
<readline/readline.h>, or check presence of /usr/include/readline.h.
As a matter of fact, this change WAS discussed. I posted an e-mail about
intended change to tech-userlevel couple of days ago.
> if it is <readline/readline.h>, then that is what should be included, not
> lame hacks added to makefile's to add the correct -I value.
Note that gdb uses normally internal readline and sets up -I
directives so that it reaches it's own copy of readline, not the
system one. It just happened to work due to how "foo.h" works. It's IMHO
better to put proper -I directive to Makefile for gdb to reach
<readline/readline.h>, than to needlessly deviate from original
gdb.
Jaromir
--
Jaromir Dolecek <jdolecek@NetBSD.org> http://www.ics.muni.cz/~dolecek/
@@@@ Wanna a real operating system ? Go and get NetBSD, dammit! @@@@