Hacker News Reader

Per the discussion in the link, specifically "All the supported languages except C and C++ are second-class citizens.", I'd seriously consider writing off everything except C, C++, and any language where someone steps up to actively support their language going forward.

Slice autotools down to 32-bit & 64-bit UNIX systems in the last couple of years (bearing in mind that if you start that today, by the time it is finished it will constitute support for the last 3-5 years)... or even all the way to current systems for the parenthesized reason... for C and C++.

Would probably also call it "Autotools 3" and slice away anything else that doesn't seem useful, on the grounds that 2.7 isn't going anywhere. If in doubt, slice it away and see what people say when you release 2.99.01.

This probably takes it down to something not so enormous to carry around.

It seems like other languages are all going their own way. Maybe that's bad, maybe that's good, most likely it's a complicated combination of both, but most importantly, there's nothing Autotools can do to stop it at this point, so you might as well roll with it.

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.

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.

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.

> 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.

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...

> 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!

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.)

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.

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

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.

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.

Aww, common, don’t put NetBSD in the same bag as Solaris. There are dozens of us!

NetBSD on x86-64: great!

NetBSD on mid-90s hardware: uhh, that's cool if you want to experiment with it or enjoy the nostalgia value, but if you're doing that, you know what you signed up for.

> NetBSD on mid-90s hardware: uhh, that's cool if you want to experiment with it or enjoy the nostalgia value, but if you're doing that, you know what you signed up for.

So why is old tech persona non grata? I'm getting so tired of this death march.

One reason is because its performance per watt is horrid. There’s an environmental cost at keeping hardware 17 Moore’s Law generations behind up and running.

... but no Intel Management Engine ...

You get that on an RPi4 with less power and more performance than some of the ancient architectures still being dragged along for the ride in some projects.

Bad example, on RPi you still have horrid proprietary blobs running.

Then pick one of the million clones that don't.

Yes, but that doesn’t mean anyone has the right to kill these architectures off.

Btw, we just saved the VAX backend in gcc.

I disagree vehemently. Upstream has every right to kill off support for them in the version they maintain. Interested parties are more than welcome to fork the software and maintain their own supported branch. That's a huge part of the appeal of Free Software!

When did it go from "Of course it runs NetBSD" to "Of course nobody runs NetBSD"?

> I'd never advocate for support for such systems to be scrubbed from the Internet. I'm just saying it's unreasonable to expect a maintainer today to support ancient systems.

The raspberry pi 3 is ancient?

>32 bit CPUs

https://www.ee.ryerson.ca/~elf/hack/ktoast.html

autotools is used for embedded systems, if you cut them out then you lose a big part of thei rusers...

Do you have any concrete examples? I see it stated as a use case, but I've never seen it in the wild.

Personally speaking, I cross-compile daily using CMake with toolchain files. Some modern RTOSes use CMake exclusively e.g. Zephyr or mBed. CMake supports quite a few open source and proprietary toolchains, and they all work perfectly well, and integrate nicely with whatever build tools and IDEs you care to use.

Interactive flashing and debugging via JTAG or SWD/SWO in CLion, Eclipse or vsCode is nice. You aren't getting that with the autotools...

Well I left the embedded industry a while ago. There was some movement towards Yocto but we used autotools for everything.

I worked in the VOIP industry ~14 years ago and in the electrical sector ~8 years ago.

That depends on how much modularization the project has. If each platform is e.g just another file it isn't that much of the problem. They can just call that platform deprecated if they don't want to maintain it anymore but will be no issue keeping it.

> 32 bit CPUs

That’d break havoc for pretty much all of OpenWRT.

GNU make is used for lots of embedded devices.