Re: Build problem on terminfo.c on FreeBSD 4.7

[Peter Stephenson <pws@pwstephenson.fsnet.co.uk>]

Oliver Kiddle wrote:
> # ifdef HAVE_CURSES_H
> #  include <curses.h>
> # endif
> 
> So curses.h would be included. However, HAVE_CURSES_H is not defined.
> This seems to be because the curses.h header check is inside this in
> zshconfig.ac:
>   case "$LIBS" in
>   *curses*)
> This presumably fails because it uses just -ltermcap.
> 
> libtermcap.so is just a link to libncurses.so here. So how is that
> situation otherwise handled? Should the HAVE_SETUPTERM test perhaps
> similarly only be done if $LIBS = *curses*? Or can we perhaps safely
> substitute -1 for ERR?

The original idea seemed to be the terminfo module was restricted to
systems which used terminfo, which was taken to imply curses.  However,
it doesn't seem to have been taken into account everywhere, and I think
the distinction is all a bit historical now.  In particular, on many
systems (like this one) termcap if it exists seems to be a vague pointer
to curses anyway, so deliberately linking against -ltermcap is
pointless.  What's more, on some other systems termcap is only
statically linked (possiably with hacked-out bits of curses, though I
don't know that) while curses, with the same symbols and more, is
dynamic.

In short, it's a mess.

Here, if curses is actually being used, whether in disguise or not, I
think we have two choices (1) continue to use the logic that applies to
termcap, i.e. not provide the functionality for terminfo (2) apply *all*
the definitions that refer to curses, including any applicable HAVE_*
stuff, changing configure as necessary.  I don't think propagating a
hybrid is a good idea.

More generally, I think the thing to do is only compile a stub terminfo
unless everything necessary is around (subject to the complications
above of what this actually means).  Probably even better would be not
to attempt to compile it; this can be done with a suitable test (which
might not be trivial, however) in the .mdd file.  On my Linux system,
the library is present but echoti simply says `not available on this
system'.  We could only compile the library at all on systems where we
know it's going to work.

There have been endless problems of this sort.  I'd *really* like to get
this sorted out before 4.1 becomes 4.2.

-- 
Peter Stephenson <pws@pwstephenson.fsnet.co.uk>
Work: pws@csr.com
Web: http://www.pwstephenson.fsnet.co.uk