Re: [patch] configure.in: revert osf5.1 no-noncurses special case

[Daniel Jacobowitz <drow@false.org>]

On Fri, May 07, 2004 at 06:19:05PM +0200, Mark Kettenis wrote:
>    Date: Fri, 7 May 2004 11:33:38 -0400
>    From: Daniel Jacobowitz <drow@false.org>
> 
>    On Fri, May 07, 2004 at 11:10:48AM -0400, Michael Chastain wrote:
>    > Hi Mark,
>    > 
>    > Yeah, I was unhappy about reverting the patch, but in the long run,
>    > the problem is not really specific to osf5.1, so it's better to
>    > solve the real problem.
>    > 
>    > > 4. Unly use ncurses if the user passes --with-ncurses to configure.
>    > 
>    > I prefer this solution the best.  We've had similar requests for
>    > readline from people who want to use the system readline library
>    > or their own readline library rather than our bundled readline.
>    > And this way a clueful user has the maximum usability, while a
>    > no-customization user has a good chance of getting a working gdb
>    > and even a gdbtui.
> 
>    I think this is a bad idea.  Remember, there's this huge base of
>    installed systems where ncurses is the default library and/or installed
>    in a system directory.  Why penalize them?
> 
> Most of the open source systems use ncurses as the native curses
> libraries.  On such systems, ncurses is either installed as libncurses
> (OpenBSD) or there is a link from libcurses to libcurses (FreeBSD,
> Debian GNU/Linux).  The headers are treated in a similar way.  I'm
> certainly not proposing to detect whether libcurses is actually
> libncurses, and refuse to use libcurses in that case.  I'm just
> proposing to search for libcurses and ncurses.h only if --with-ncurses
> is specified.
> 
> I really doubt that there are really any systems out there where
> ncurses is installed in a system directory alongside with the native
> curses library where the two are not one and the same.  If there are
> such systems out there, we'd only penalize them if the native curses
> library is somehow broken.

I would have expected there to be such systems.  Maybe there aren't. 
In any case, ncurses is the GNU curses library, so I still think it's
appropriate to prefer it.

> It's broken in my book too, but it's very likely that you'll end up in
> that situation if you install GCC and ncurses using
> 
> ./configure && make && make install
> 
> on almost any UNIX system.

At which point it's the user's responsibility to set LDFLAGS, IMO. 
Note that if you do that with ncurses, you'll probably get a shared
library in a non-system directory, so this is just the beginning of
your problems.

-- 
Daniel Jacobowitz