In general, in my experience, autoconf makes for less portability, not
more.
As an anecdotal data point, Jay Maynard has forked Hercules (S360/370/390/z
Emulator) and, among other things, is ripping out 25 years of
increasingly-baroque autoconf, which will probably make the build process
(notoriously finicky) a whole lot clearer and easier.
Adam
On Thu, Jun 20, 2024 at 1:12 PM ron minnich <rminnich(a)gmail.com> wrote:
The slurm configure, produced by the configure script,
is 1 mbyte, 30,000
lines of impenetrable script. For each .c file in slurm, an 11960 line
libtool script is invoked. autoconfig uses m4. When I told Eric Grosse,
back in 2015, that *anything* still used m4, he would not believe it was
"the m4 from the 70s" until I showed him. He was speechless. He had assumed
m4 died in the 80s.
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.
For a good example of a very portable system with a very clean,
human-readable make setup, I'd recommend a look at plan9ports. It includes
2 window managers, 2 graphical editors, and all the Plan 9 tools, and
somehow manages to be at least as portable as the autoconf mechanism.
On Thu, Jun 20, 2024 at 12:59 PM Warner Losh <imp(a)bsdimp.com> wrote:
> For me, precomputing an environment is the same as a wysiwyg editor: what
> you see is all you get. If it works for you, and the environment that's
> inferred from predefined CPP symbols is correct, then it's an easy
> solution. When it's not, and for me it often wasn't, it's nothing but
pain
> and suffering and saying MF all the time (also not Make File).... I was
> serious when I've said I've had more positive cmake experiences (which
> haven't been all that impressive: I'm more impressed with meson in this
> space, for example) than I ever had with IMakefiles, imake, xmkmf, etc...
> But It's also clear that different people have lived through different
> hassles, and I respect that...
>
> I've noticed too that we're relatively homogeneous these days: Everybody
> is a Linux box or Windows Box or MacOS, except for a few weird people on
> the fringes (like me). It's a lot easier to get things right enough w/o
> autotools, scons, meson, etc than it was in The Bad Old Days of the Unix
> Wars and the Innovation Famine that followed from the late 80s to the mid
> 2000s.... In that environment, there's one of two reactions: Test
> Everything or Least Common Denominator. And we've seen both represented in
> this thread. As well as the 'There's so few environments, can't you
> precompute them all?' sentiment from newbies that never bloodied their
> knuckles with some of the less like Research Unix machines out there like
> AIX and HP/UX... Or worse, Eunice...
>
> Warner
>
> On Thu, Jun 20, 2024 at 12:42 PM Adam Thornton <athornton(a)gmail.com>
> wrote:
>
>>
>>
>> Someone clearly never used imake...
>>
>>
>> There's a reason that the xmkmf command ends in the two letters it
>> does, and I'm never going to believe it's "make file".
>>
>> Adam
>>
>> On Thu, Jun 20, 2024 at 11:34 AM Greg A. Woods <woods(a)robohack.ca>
>> wrote:
>>
>>> At Thu, 20 Jun 2024 01:01:01 -0400, Scot Jenkins via TUHS <
>>> tuhs(a)tuhs.org> wrote:
>>> Subject: [TUHS] Re: Version 256 of systemd boasts '42% less Unix
>>> philosophy' The Register
>>> >
>>> > "Greg A. Woods" <woods(a)robohack.ca> wrote:
>>> >
>>> > > I will not ever allow cmake to run, or even exist, on the machines
I
>>> > > control...
>>> >
>>> > I'm not a fan of cmake either.
>>> >
>>> > How do you deal with software that only builds with cmake (or meson,
>>> > scons, ... whatever the developer decided to use as the build tool)?
>>> > What alternatives exist short of reimplementing the build process in
>>> > a standard makefile by hand, which is obviously very time consuming,
>>> > error prone, and will probably break the next time you want to update
>>> > a given package?
>>>
>>> The alternative _is_ to reimplement the build process.
>>>
>>> For example, see:
>>>
>>>
https://github.com/robohack/yajl/
>>>
>>> This example is a far more comprehensive rewrite than is usually
>>> necessary as I wanted a complete and portable example that could be used
>>> as the basis for further projects.
>>>
>>> An example of a much simpler reimplementation:
>>>
>>>
>>>
http://cvsweb.NetBSD.org/bsdweb.cgi/src/external/mit/ctwm/bin/ctwm/Makefile…
>>>
>>> --
>>> Greg A. Woods <gwoods(a)acm.org>
>>>
>>> Kelowna, BC +1 250 762-7675 RoboHack <woods(a)robohack.ca>
>>> Planix, Inc. <woods(a)planix.com> Avoncote Farms
<woods(a)avoncote.ca>
>>>
>>