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

[ron minnich <rminnich@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 5138 bytes --]

and, this just happened in slurm:
autoreconf
at top level of slurm fails with an m4 error complete with the usual
incomprehensible error message.

This gets old. As the saying goes, autoconf tools may be slow and buggy,
but at least they're hard to use.

one of the things I am grateful to Go for is that it does not suffer from
this sort of nonsense.

On Thu, Jun 20, 2024 at 1:12 PM ron minnich <rminnich@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@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@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@robohack.ca>
>>> wrote:
>>>
>>>> At Thu, 20 Jun 2024 01:01:01 -0400, Scot Jenkins via TUHS <
>>>> tuhs@tuhs.org> wrote:
>>>> Subject: [TUHS] Re: Version 256 of systemd boasts '42% less Unix
>>>> philosophy' The Register
>>>> >
>>>> > "Greg A. Woods" <woods@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@acm.org>
>>>>
>>>> Kelowna, BC     +1 250 762-7675           RoboHack <woods@robohack.ca>
>>>> Planix, Inc. <woods@planix.com>     Avoncote Farms <woods@avoncote.ca>
>>>>
>>>

[-- Attachment #2: Type: text/html, Size: 7602 bytes --]