On Wed, 2 Feb 2022 18:52:55 +0100 (CET) [email protected] 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.
