Hacker News Reader

Comment by rbanffy | Hacker News Reader

Identifying the moment we need to stop supporting a platform is frequently non-obvious. Unisys still supports MCP (as Clearpath OS), VMS is supported and was ported to x86, Atos supports GECOS, and some people are making CP/M fit inside dedicated word processors. A couple months back there was a report of ncurses failing on Tandem NonStop OS (still supported, IIRC, by HPE). As long as something works, we'll never hear about all those wonderful exotic platforms people still use for various reasons. There must be a lot of PCs controlling machinery doing GPIO through parallel ports while emulating PDP-8's with some poor intern having to figure out how to make changes to that code.

View on HN

Here's a simple criterion I propose: is the platform disbanded?

For example, in GNU Make's dir.c file. There's a lot of stuff like this:

    #ifndef _AMIGA
        return dir_file_exists_p (".", name);
    #else /* !AMIGA */
        return dir_file_exists_p ("", name);
    #endif /* AMIGA */

There should be a foreseeable date when we can say, "OK the Amiga maintainers have added a feature that lets us use '.' as a directory so we can now delete that #ifdef". But that day is guaranteed to never come, because the Amiga project is disbanded. So should we keep that until the heat death of the universe?

I would propose that we instead say, if you use Amiga, there's great support for it in versions of GNU Make up until x.y.z. So if you love old Amigas, you'll be well served using an older version of GNU Make. I think it's straightforward.

This kind of thing shows why ifdefs are usually the wrong tool for multi-target projects.

There should be a platform adapter API instead that defines a shared header with function names for these actions, multiple platform-specific implementation files, and only one of them gets compiled.

That way you could simply ignore the existence of "filesys_amiga.c", and then maybe delete it 50 years from now.

(I realize it's probably not realistic to do such major internal surgery on Make at this point.)

This was one of the brilliant aspect of Knuth's web system: You could have change files that would be applied to the immutable source to manage ports to individual platforms.¹ I really wish that this sort of patching had spread to other programming paradigms.

⸻

1. It works even on somewhat actively developed code since the likely to require porting parts of the program could be clumped together in a web source file and, once isolated, generally saw few if any changes. I remember maintaining the public domain vms change files for the TeX 2–3/MF 1–2 upgrades and as I recall, even with these significant changes to the programs, no updates for the change files were necessary.²

2. Most of the work that I did back then in maintenance was centered around enhancements to the VMS-specific features. For example, rather than having iniTeX be a special executable, instead, iniTeX features could be enabled/disabled at runtime from a single executable.³ Similarly with debug code.

3. This feature appeared soon after in the web2c port of TeX and friends, but I think that Tom Rokicki might have got the idea from me (or else it was a case of great minds thinking alike in the late 80s).

> This was one of the brilliant aspect of Knuth's web system

As they say, those who don't know the past, are bound to repeat it.

I respectfully disagree to this very common argument against ifdefs, and will also point out that developers who hold this anti-ifdef belief hold it quite strongly! I generally prefer the ifdef-style.

What do you mean by 'disbanded'? Should FOSS stop support the moment a manufacturer discontinues a device/platform?

That's what Homebrew does

Why on earth do you need to hack on GNUMake in the first place?

It’s old software which has far better and faster replacements like Ninja.

The whole design of Make itself is outdated and inefficient which is why tools like Ninja are much faster.

Maybe because tons and tons of software build with GNU make, not with Ninja, and if you want to be able to build that software, you need GNU make?

Also, Ninja by itself is not really a replacement for GNU make. Rather it's a tool one can build such a replacement on, so the comparison is a bit off to start with...

The Cosmopolitan Libc repo uses GNU Make. It builds 672 executables, 82 static archives, and 17,637 object files and runs all unit tests in under 60 seconds on a $1000 PC. How fast would Ninja do it?

make has a -j switch.

> But that day is guaranteed to never come, because the Amiga project is disbanded. So should we keep that until the heat death of the universe?

Surely there are more options "keep that until the heat death of the universe" and "remove that the moment its platform is out of production". A more practical metric for free/open software, I think, would be "is there still someone maintaining this software on this platform": every major release (e.g., 5.x -> 6.0) could be a time to do a sanity check, documenting ports that don't have an active maintainer as "deprecated". At the next major release, if nobody's stepped up to maintain it, then it gets removed. (One could argue even that's too draconian, because there may be people still using the port even if it's not maintained.)

> is the platform disbanded?

amigaos had a major new release less than a year ago so i guess the amiga ifdefs should stay

All three users rejoice! ;-)

Surely this is a problem of source code organisation not multi-platform support? A better model would be having clearly articulated platform/arch specific files doing all the per-platform/arch defines, which then get included for the target specific build. However, reorganising a code-base this way when it wasn't like that at the outset is can be a fraught (and hard to justify) exercise.

A good example of source code organisation that does a decent job of separating per-platform concerns, is the Nethack code base.

Reply on news.ycombinator.com