21 Jun
2024
21 Jun
'24
10:06 p.m.
On Fri, 21 Jun 2024 at 11:47, Chet Ramey via TUHS <tuhs(a)tuhs.org> wrote:
On 6/20/24 4:12 PM, ron minnich wrote:
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
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.