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

[mec dot gnu at mindspring dot com (Michael Elizabeth Chastain)]

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.

> 1. Prefer a system's native curses library over ncurses.

My second choice, because it's simple.

> 2. Only use ncurses if we can find both the headers and the associated
     library.
   a. Error out if one of the parts if missing.
   b. Fall back on the system's native curses library if something is
   missing.
> 3. Try harder to find all ncurses components by fiddling with CPPFLAGS
   and LDFLAGS.

These are equally meh to me.  I agree with your assessments of 2a, 2b,
and 3.

The advantage of the current scheme (option #0) is that it might work
on some systems.  I'm unhappy with #0 because I know that it doesn't
work on my hp test drive system.  As I understand it, you are unhappy
with #1 for the converse reason: the configury can automatically make
a bad choice on some systems.

There are actually several flavors of 4:

  4A. if --with-ncurses is not specified, always use curses
  4B. if --with-ncurses is not specified, probe for ncurses automatically anyways

I like 4A because it's simple and it gives full control.
But it doesn't automatically work on some systems where a different
plan would automatically work.

Michael C