I love this example, but more because it shows just how obtuse make is even for simple programs. There's one self-explanatory line in this whole program (`SRCS = foo.cpp bar.cpp baz.cpp`), and everything else is magic you'd just have to cargo-cult forward.

I _think_ that it's also broken, if I copy-paste it: your comment renders with spaces in the `clean :` stanza, but I believe make requires that to be a tab character?

While certainly simplistic, the bazel example shows one obscure feature (glob) that's both still fairly obvious, and unnecessary for a direct comparison to your example. The rest reads clean, and could be replicated/modified by someone with no clue fairly straightforwardly.

Don't get me wrong, bazel BUILD files will often hide a whole lot of magic. But the benefit is, for a newcomer the files they have to interact with on a day-to-day basis are friendly. Take tensorflow, one of the most complicated bazel repos I know - browse to a random leaf BUILD file and you'll probably find it quite readable. (I randomly clicked to https://github.com/tensorflow/tensorflow/blob/master/tensorf... , seems pretty clear - especially when I consider it's compiling kernels for GPUs, which I know nothing about.)

(Disclaimer: Googler, work closely with the bazel team. I like bazel.)

The `SRCS = foo.cpp bar.cpp baz.cpp` was my fav part. I like to put every file used into a Makefile instead of using globs, but my example also showed how without editing the file someone can build with globs instead ;) Similar approach if you need the program to be named winApp.exe instead... That's another 'beauty' of make, you don't have to edit the Makefile.

There's really not much cargo cult in my example. Everything would be in the most rudimentary doc or tutorial, certainly less reading than if you needed to use git for the first time.

And yes there is supposed to be a tab there, some copy-paste thing munged that.

If that was the case, autoconf and autotools would have never been a thing.

The "beauty" of UNIX falls apart when trying to code across all of them.

For example, I cannot even remember if that Makefile would work 100% with a POSIX make.

That Makefile works with BSD and GNU make, no extensions used.

Bazel isn't really nicer than the autotools when you need something complicated, if it even supports your platform. Here's a fun bazel bug report: https://github.com/bazelbuild/bazel/issues/4350#issuecomment...

I've always managed to avoid autotools unless it was used before with things like LDFLAGS='-lsocket -lns' make ...

For me being POSIX compliant goes a little beyond BSD and GNU make.

What does posix compliant* even mean for make? The posix standard doesn't even require support for c++! That's a VERY portable Makefile. It would work on any make from the late seventies (assuming you also had a c++ compiler and system Makefiles that knew how to use it). It only uses a small subset of the rules in the standard.

* https://pubs.opengroup.org/onlinepubs/009695399/utilities/ma...

That is what I mean by POSIX compliant, so I stand corrected. Thanks.

The difference being that interpreting makefiles requires tons of experience whereas the equivalent build rule above is obvious to anyone.

Are you kidding? I have no clue what half of those lines are doing. And only any idea about the other half because I've come across make before. I also highly doubt that this will run on windows, whereas the Bazel build probably will.