On 6/20/24 4:12 PM, ron minnich wrote:
> Personally, the autoconfig process does not fill me with confidence, and it
> was recently responsible for a very serious security problem. And,
> autoconfig doesn't work: I've lost track of how many times autoconf has
> failed for me. In general, in my experience, autoconf makes for less
> portability, not more.
I'd be interested in some examples of this. I've had pretty decent success
with autoconf-based portability.
I think it's important to make a distinction between autotools not working and the actual software distribution not being buildable.
For example, I've recently been working with Ultrix V4.5. Most configure scripts are able to complete successfully with ksh or sh5, so I don't absolutely need bash (even though I do have it and use it). The difficulties begin when trying to compile the actual code; for example, Ultrix doesn't have strdup(). Almost every autotools-based package I've used doesn't bother checking if I have strdup() and/or providing a replacement. This isn't the fault of autotools, this is the fault of the code author not considering whether a lack of strdup() is a possibility. The end result, however, is the same - I don't have a buildable release as-is.
I know that Ultrix is incredibly out of date, but I use it to illustrate that while there are corner cases that autotools won't catch, that isn't the fault of autotools. It would be no different with cmake or imake or meson or handwritten makefiles or anything else - if the software author doesn't bother checking for and coding around the corner case that comes up on your particular system, you're stuck unless you can fix the code.
-Henry