Hacker News Reader

> Not sure I will write my Makefile generator, since my project is also not that big.

gcc has a family of command-line options starting with -M than can generate dependencies as a byproduct during compilation. The generated files are in Makefile format, and only need to be included in your main Makefile.

https://make.mad-scientist.net/papers/advanced-auto-dependen...

I never understood how anyone can be fine with dynamic build dependencies?

Each and every build tool should be version pinned so that two build runs today and 4 years ago produce the same (hex neutral) executable.

Otherwise debugging issues becomes a nightmare...

I doubt many would disagree in principle but that's very expensive. You need to maintain old machines too (well, old OSes) as the old compiler may not run the same on newer versions (file locations, shared libraries, etc).

Years ago I had a customer who wanted to freeze a toolset and wanted to be sure that any bug fix they requested changed only the lines of code relevant to the bug (they diffed the binaries and traced each change back to our source change to be sure). They paid an enormous premium for this capability.

I would totally love to read a blog post about this. One can imagine an embedded tools gig where this would be important for a long-term support. Did they also do something like buy multiple copies of A specific hardware configuration of the target computer for preservation?

I don't remember what they did on the host (development) side. This was more than 25 years ago.

They were a major phone switch manufacturer (long since absorbed by someone else). Their original design was, IIRC, a Z8000. As those parts were EOLed they shifted to the 68K and wrote a Z8000 emulator for the 68K. They later shifted to the PPC and ported their Z8K emulator to the PPC. We supplied a frozen version of the GCC PPC cross compiler. They had their own frozen version of a Z8K toolchain I think.

Their SLA was something like "less than five minutes of downtime per decade" -- no rebooting, realtime performance, no other interruption -- and they believed their extreme conservatism helped them get there.

> "less than five minutes of downtime per decade

Wow.

Well, if they were willing to pay…

Thanks very much for that wonderful piece of history.

Hold on, I just realized something.

Does this mean their hardware may still be running on a Power PC that is emulating a Z8000 that is emulating a 68000?

It would have been "running on a Power PC that is emulating a 68K that is emulating a Z8000". We used to joke about that.

But in fact they changed from "running on a 68K that is emulating a Z8000" to "running on a Power PC that is emulating a Z8000".

They ported their Z8K emulator from 68K to PPC which wasn't super hard. When the PPC was designed it was planned as an upgrade path from 68K series (remember it was a JV between Apple, Motorola and IBM; the first two, at least, had vested interests in making that transition as easy as possible).

This whole stack of emulation sounds crazy but given their needs, it wasn't.

Thanks for scratching my itch. Fun fun story with just the right ending.

The web in general may be fine with this. But in the real-time domain (planes, cars, machinery, assembly lines...) you cannot allow uncertain behaviour caused by a shaky build environment

You say the web like this isn’t also true of basically every Linux disto in existence. The ability to build software against many different sets of libraries is what enables the Linux userspace to work.

All you need is to run the build in a VM (a container/chroot also works almost always since the Linux kernel maintainers are committed to not breaking userspace).

It's not done usually because it's also very useful to take advantage of new language and library features and all software is supposed to not break compatibility with new versions, so if there is an issue due to upgrading it's because an incompetent maintainer failed at their job.

> I never understood how anyone can be fine with dynamic build dependencies?

There's 132,059 lines of Makefile code that's generated to o/$(MODE)/depend e.g.

    o//libc/stubs/gcov.o: \
            libc/stubs/gcov.S \
            libc/macros.internal.h \
            libc/macros.internal.inc \
            libc/macros-cpp.internal.inc \
            ape/relocations.h

That much code can't be written by hand, and if you don't write that, then your build targets won't be invalidated correctly. You'll end up with a non-deterministic unreliable build, which is much worse than generating some unfancy make that causes the make process to bootstrap itself. Goal is to get those hex perfect reproducible binaries with minimal toil.

Also, when you write build configs, do you depend on system-provided tools and libraries? Such as some .so file or the python interpreter? The cosmopolitan mono repo doesn't do that. It currently only requires the make, sh, zip, mv, rm, touch and gzip commands. I'd ideally like to make it more hermetic but so far that hasn't been an issue, since the above tools are so stable.

> I have been working with Bazel in my personal monorepo (~6 months now), and the fact that Justine, someone I believe knows Bazel/Blaze well, uses GNU Make, makes me re-think my decision: perhaps I should re-consider it. I have quite a few issues with Bazel, which require significant engineering hours to overcome, whereas I could just use gnu make and solve it quickly.

It simply represents different tradeoffs of convenience vs. correctness. With Bazel, you get correctness but you pay a complexity price.

Have you tried https://redo.readthedocs.io/ ?