On Fri, 21 Jun 2024 at 11:47, Chet Ramey via TUHS <tuhs@tuhs.org> wrote:

> 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