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!  @@@@