[TUHS] Version 256 of systemd boasts '42% less Unix philosophy' The Register

[Adam Thornton]

>
> 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 at 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 at 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 at 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 at robohack.ca>
>>> wrote:
>>>
>>>> At Thu, 20 Jun 2024 01:01:01 -0400, Scot Jenkins via TUHS <
>>>> tuhs at tuhs.org> wrote:
>>>> Subject: [TUHS] Re: Version 256 of systemd boasts '42% less Unix
>>>> philosophy' The Register
>>>> >
>>>> > "Greg A. Woods" <woods at 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?rev=1.12&content-type=text/x-cvsweb-markup&only_with_tag=MAIN
>>>>
>>>> --
>>>>                                         Greg A. Woods <gwoods at acm.org>
>>>>
>>>> Kelowna, BC     +1 250 762-7675           RoboHack <woods at robohack.ca>
>>>> Planix, Inc. <woods at planix.com>     Avoncote Farms <woods at avoncote.ca>
>>>>
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.tuhs.org/pipermail/tuhs/attachments/20240620/9fb5171f/attachment.htm>