LYNX-DEV http://www.flora.org/lynx-dev/html/month0398/msg00120.html

[Jonathan Sergent]

  I'm new to this reply-from-the-list-archive thing, sorry if this 
  message is messed up looking.

 (Tom wrote:)
>no problem - I'm looking for details.  The fix looks plausible (figuring
>out the possible values from config.guess isn't easy except by running the
>script on the right sort of box).  Comparing with the 9.05 config.cache,
>I think you're right.

I added an "echo dink dink $host_os" (gimme a break, it was 3am) before 
the case statement and confirmed that $host_os was set to "hpux10.20" on
these machines.

>> Did the configure test ever work?  Hmm.
>maybe not - I've only gotten vague reports about anything but ncurses.

Yup, I am trying to make this a non-vague report about something other
than ncurses.  I can say with some certainty that SLANG also works with
recent Lynx versions out of the box, since I use it every day with 
ac-0.10something.

>My impression is that HP got stuck supporting a variant of SVr3 curses
>which has been obsolete for some time (SVr4's been there a while), and
>someone decided to rename the old curses to Hcurses.  (But that's a guess).

libcur_colr is also a possibility, and also does not crash.  Should I try
it with it checking for libcur_colr before it checks for libHcurses?
If the configure script can detect whatever sort of color support that 
libcur_colr has in it that would be good.  It might be weird and have
incompatible color support, though.  I can work on this again tonight.

>I was unable to use /bin/cc (K&R) because it did not parse the 'assert()'
>statements in GridText.c (but someone reported no problem - perhaps it's
>a missing patch to cc, or something like that).

We have the ``unbundled'' C compiler here which has ANSI mode (and 
configure is smart and figures out the flags it needs for ANSI mode).
It seems to work pretty well, whereas gcc for HP-UX has always seemed
to have some compatibility problems...

>I'd like to release it this weekend - so far we've found several minor
>bugs (and become more aware of the design differences between 2.7.2 and
>2.8pre).  If we go back & redesign before release, however, I don't believe
>it'll be released.

Okay.  I'm in a software engineering class right now, and ``goldplating of
requirements right before delivery date'' is something that has come up in 
class as quite a bad thing.  Doing a release should add to the momentum
here rather than slow it down.

You do think you can incorporate this minor autoconf change, though, 
right?

-- 
Jonathan Sergent / address@hidden