Re: libtermcap

[al davis]

On Wed,  2 Feb 2022 18:52:55 +0100 (CET)
karl@aspodata.se wrote:
> If it just me, I'd just edit the files to suit my system.

That's what I would do.

In your case, it looks like the problem was that libtermcap was not
installed properly.  I link was missing.

> 
> But your message makes me ask:
> 
> 1, what systems should gnucap support, and how old ?

I have no problem with omitting the test for termcap.  That's easy.

I think the real reason the test is there is to hide a problem with
some systems that had a messed up installation of readline, which
didn't work unless termcap was also installed.  That was before the
popularity of package systems like apt and yum, which keep track of
things like that.  So, the test for termcap should be dropped, because
it is not explicitly used by gnucap.  It was used implicitly through
readline.

As I recall, it was an issue on mostly BSD systems, which did all they
could to avoid anything GNU.

Even so, when you got that compiler message, indicating that the test
for readline failed, the script should have continued, and let you
build without readline.  It should have compiled correctly after that,
with the only consequence being the loss of features that would have
been provided by readline and/or termcap.  That should have happened
without editing any files.

Back then, a similar situation with autotools would have failed, just
failed, giving very little information.  So you look at the log, scroll
back, see that compiling the test program failed, maybe.  Then you could
decide what to do.  It was a real mess.



> 
> 2, do you want to scrap gnucap configure scrips and use autotools 
>    instead ?

Autotools has almost always been available as an option, but I could
never get it to work properly.  The proponents of autotools have
different expectations for what "properly" means.

There was one time that gnucap (or its predecessor acs) did use
autotools as the default build system.  It turned out to be such a
problem that I switched it back to the old scripts, which date back to
before autotools was available.  The switch back came at the same time
as the transition to plugins and the library (libgnucap).  This
abandonment of autotools was a key factor in the development of the
plugin system, which in a technical sense has been beneficial well
beyond the original goals.

One issue goes back to "I'd just edit the files...".  In a practical
sense, autotools takes away that option.  The files are such a mess
that "just edit the files" becomes impossible for those not in tune
with autotools.  Sometimes I think "just edit the files" is the best
way.  "Make" is really a nice programming language.  Autotools takes it
away, burying it under its own set of scripts and m4 macros.