I don’t object to “it works for me”, but “it’s really not all that difficult” is a bad generalization.

* If you need portability, Makefiles are hard.

* The whitespace design of Makefiles is bad and has swallowed up countless debugging hours over the years. This design flaw isn’t intrinsic to the way Makefiles work, it’s just a lousy artifact from a superficial decision from decades ago: to change behavior based on distinctions invisible in source code. It’s mitigated by syntax highlighting but still bites people.

* Makefiles are dependent on the consistency of the build environment, for example the availability and behavior of command line switches. Even if your project doesn’t need OS platform portability, this is still a pain across time and requires external tooling to manage.

* There are certain subtleties to the way Makefiles behave that are addressed by `.PHONY`. I agree that these are manageable in the absence of other complexities, but they contribute towards Makefiles being more difficult than appears at first.

I’m sure you’re familiar with those critiques and others. They may not bother you, but you don’t speak for everybody.

My Makefile is portable. It builds binaries that run on six OSes and two architectures. So I used my Makefile to build GNU Make and a GCC toolchain. Now I can run my Makefile on any of those OSes / architectures too, and it'll produce the same deterministic output, bit for bit.

If part of your build is building your own build tool in order to ensure you have the proper build tool then why not build a different “better” build tool?

Part of the premise of Make is its ubiquity, but if you can’t rely on that save as a simple bootstrap (as you seem to be doing) then why not forego it for something else?

> (..) then why not forego it for something else?

Because blindly ditching a technology for no reason at all is not a way to fix problems.

Are you suggesting this: https://xkcd.com/927/ ?

My project is literally to make a compiler toolchain. Do you expect me to not use it? The nice thing is that you can build my project on any computer that has modern GNU Make. That and sh are the only things that needs to be installed.

> My Makefile is portable.

Oh yes, in the good old tradition of "... as long as it's some Linux on x86".

    [...] on Linux 2.6+ (or WSL) using GNU Make. 

Sorry, it's actually AMD64 _and_ ARM64!

People use Windows toolchains and nobody cares. Those are significantly less portable. But here I am, building with Visual Studio.

You might want to take a look at the "actually portable executable"* project, made by the person you're responding to. There may be tips that will make make more approchable to you, if you're still dealing with MAKEFILEs.

* https://justine.lol/ape.html

Projects of much smaller sizes often have recursive convoluted makefiles.

> Projects of much smaller sizes often have recursive convoluted makefiles.

You name any technology and anyone can enumerate dozens of projects that use it wrong.

I’d walk that before talking. Take any complex makefile system and turn it into a single “not really difficult” makefile without sacrificing anything important. Wins this argument and helps those who “use it wrong”.

And I can show you thousands of "Hello World"s that use GNU Autotools or CMake ;)

But seriously: can I take a look at it (Soource + Makefile)?

This is most likely what is being referenced: https://github.com/jart/cosmopolitan/blob/master/Makefile

I like how the includes are separated and commented.

Also if you weren't already familiar with their work you might be interested in giving this a read: https://justine.lol/ape.html

Can

  % grep '^include' Makefile -c 
  159

includes with

  % wc --lines --total=only $(awk '/^include/{ print $2 }' Makefile) Makefile 
  22547

lines in total really count as having a single makefile? I have no dog in this fight, just wondering.

Sure buddy anything can be manageable once you invest enough time and sanity.

Now show us the Makefile.

> I work on a project with 4.4 million lines of code [...] It's really not all that difficult.

You may be biased.