Hacker News Reader

Comment by yjftsjthsd-h | Hacker News Reader

If you're going to cut off the long tail of compatibility, what's the point of using autotools? I thought the whole point of autotools was to deal with the (painful) diversity of operating systems.

View on HN

Because at some point, who really cares about those ancient systems? Suppose I'm writing a program that uses autoconf, and it detects that someone is trying to compile my program on an Amiga using gcc 2.95. Well, awesome for them if they make it work, but I'm not willing to put in any effort to support that in my code.

What are the long tail of variants that people actually care about now? 32- vs 64-bit, OK, sure. 36-bit? No way. Big- vs little-endian, sure. PDP-endian? Miss me with that.

It just seems like the number of variations that people plausibly care to support is a lot shorter than it use to be. Why should the autoconf gang work themselves to the bone making sure their stuff works correctly on a platform that no one but a platform's maintainers actually cares to target?

I'm not unsympathetic to people using old or odd systems. I've got some bizarre stuff squirreled away in my attic. I don't reasonably expect anyone but me to put effort into keeping my SPARCstation 5 limping along, though.

> Because at some point, who really cares about those ancient systems?

A lot of people do. Retro-computing is way more popular than you would think.

In fact, m68k is the oldest port in the Linux kernel and is so well-maintained that it saw multiple other architectures come and go.

I ran that on my Amiga when it was still new. I have no animosity toward it! But should someone in 2021 still have to expend effort to support that in upstream tools?

Yes, this is open source, everyone is free to chose how they contribute.

I side with the parent here, if you don't care about portability why even bother with the autotools? And if you bother to use the autotools, what would you get by purposefully breaking compatibility?

I'm still to this day paid to write embedded code for various DSPs, I'm very happy that autotools are portable. I know that on HN if you're not writing NodeJS or Rust in x86-64 docker containers you're niche and don't count, but it's a bit short sighted.

Autotools doesn't need disrupting.

I even think that the mail in TFA is somewhat mislead. Autotools drop in popularity because the type of software development that requires using the autotools is slowly but surely declining, or maybe it's not even declining but simply growing at a fraction of other ecosystems. Actually many modern languages and environments (IMO rightfully) ship their own well-integrated build systems, so attempting to bring the autotools there is probably a waste of time.

For me asking about "future plans for Autotools" is like asking for "future plans for Make" or "future plans for ls". I don't expect any substantial changes in these projects, but I also don't think they're obsolete. They just fit a specific use case and they do it (mostly) well.

I too have been paid to write DSP code, and autotools would not have helped. You can't run m4, perl, sh, or make on the DSP. Cross-compiling with autotools is far more difficult than cross-compiling with a simple little Makefile.

Exactly my thought.

Please leave autotools alone and don’t “improve” it.

It’s not like there are tons of build systems already and if someone is so keen in a heavy-weight build system, they can use Bazel which is so bloated that it doesn’t build on any 32-bit target in Debian.

There is nothing wrong with improving, just make sure you have a frozen version that can handle the old cruft, some software is so stable that you wouldn't dare to update, I have some software I made myself that does what it was designed to do and never give problems. However it does not keep one from ever going forward and design new ways of solving the same problems. So my advice would be freeze and move on.

Bazel is obviously an insane idea, but autotools is as "heavy-weight" a build system as they come. I struggle to imagine something more convoluted and bloated than autotools.

It's convoluted because of the efforts to avoid bloating by e.g. reusing the macro processor from sendmail rather than writing its own.

That diversity no longer exists. These machines only run in museums, if at all.

Plenty of industrial systems have been working fine, unchanged, for decades.

An example off the top of my head -- a CNC mill at my previous job, purchased new perhaps ten years ago, runs DOS 6.22 with Windows CE on top. I suspect that the vendor is still selling the same software stack on the same hardware today.

Before someone chimes in to say, "That's insane, why isn't it running an RTOS?": That mill had zero software faults in the years I worked with it.

Edit: Poking around Trak's website, it looks like the software on today's machines is unchanged. Here are some example screenshots: https://www.southwesternindustries.com/software/page/prototr...

And they will continue to run. No one in their right mind will ever upgrade the software on them. That is a lot of the reason behind removing old platforms from Linux: whatever the systems out there are running, it's not a HEAD kernel release.

HEAD kernel runs fine on my Amiga 4000 from 1992.

It also runs fine on my SH-7785LCR SuperH board where I regularly test the latest kernel releases and patches.

Even if that were true (and it's not completely true by the way) autotools is not used to build the kernel. You can very much use autotools to build modern software for older kernels. That's... kind of the point of using something like autotools.

Frankly reading this thread I think many people here bark at the wrong tree. If you don't care for portability don't bother with autotools, just write Makefiles. It's much simpler.

Plenty manufacturers ship software updates to 32 bit devices. Plenty 32bit devices are being sold or even newly released right now.

Do those systems need new software to support them in 2021? If they used autotools, say, they could snapshot the last working version that worked with their system and not care what the new version does. It's not like there are a lot of fixes being merged in these days to handle 30 year old systems.

> An example off the top of my head -- a CNC mill at my previous job, purchased new perhaps ten years ago, runs DOS 6.22 with Windows CE on top

I thought Windows CE was a standalone operating system like current Windows versions are, not a layer on top of DOS like Windows 3.x and earlier were.

But, Googling, I see Windows CE, on x86, did use DOS as a bootloader, just like how Windows 9x did. DOS boots, then runs LOADCEPC.EXE to start Windows CE. (By contrast, CE on other CPU architectures didn't do this, it just booted Windows CE directly.)

> Before someone chimes in to say, "That's insane, why isn't it running an RTOS?"

I'm chiming in to say that Windows CE is an RTOS. [0]

[0] https://docs.microsoft.com/en-us/previous-versions/windows/e...

Whoa. I sit corrected!

How often does someone compile and run new software on those machines? And also, let's be honest, autotools and windows have never worked well together.

That’s not true. A lot of embedded stuff is still 32 bits.

The simpler the hardware, the higher the reliability and the smaller the power consumption.

Come on. Next time you get rid of some electronic device I recommend that you open it and try looking for the main controller. You might be surprised to find that it's not in fact all running on Ryzen and Apple M1 CPUs.

Statements like these make me question one's nerd cred

My previous employer has several hundred x86-based Linux field installations. Other hotspots include IoT and industrial control systems, to say nothing of all the legacy servers still out there in current use

Anybody with intention to work on older systems can work with older releases of Autotools, while newer releases can focus on much more needed features.

Reply on news.ycombinator.com