Hacker News new | ask | show | jobs
by aleph_minus_one 560 days ago
> The thing about Makefiles is that simples ones at least are really easy to write, and read. Much simpler and quicker than a cumbersome python script, that will most likely do less with much more boilerplate code (e.g. dependencies), and be much harder to read.

Whether this is true or not depends a lot on from which programming culture/background you come.

3 comments

I honestly don't think so, and I think this is here is a prime example for proving that.

For example, a Makefile that does the same job as the build.py script in this project would be significantly smaller, simpler, and easier to read in several metrics that I'd reasonably call "objective" to a certain degree.

In fact, contrast the Makefile in that project: https://github.com/keyvank/30cc/blob/main/Makefile

With the build.py script: https://github.com/keyvank/30cc/blob/main/build.py

You need to know very little about Makefiles to make immediate sense of what that Makefile is doing, whereas you need to know much more about python to still not immediately see what the build.py script is doing. In fact, you will probably just "guess" that the python script is supposed to do a similar job only from its name before that.

And then the python script still does not do incremental builds at all!

Again, if it gets more complex that can change, but this is far away from that. It takes 10 or so minutes to learn enough about Makefiles to be productive with them, from scratch.

A Makefile dependency:

  Left : right
Left depends on the right. I don't think the ability to learn that concept is related to programming culture/background. What follows below that is what happens.

  Left : right
         cp right Left
         echo and so on. Left is now updated.
The only tricky part of the above, and something I guess nobody has found any good reason for, is that the whitespace in front of the statements ('cp' in this case) has to be an actual tab, just spaces won't do.

When it comes to the more "advanced" concepts (wildcards etc) there are slight differences between Make versions. And to bother with that is to get into the mindset which created the (argh) Automake and Autoconf systems (to begin with), so back in the day our company simply decided that we'll use GNU Make on every single system (we supported lots of various UNIX systems) and not bother with any of that (no SYSV Make, no BSD Make or anything), because GNU Make was and is available on anything and everything. Made life very simple back then.

The story I have heard about why it must be a tab is that by the time the author of the original Make realised he didn't need to require a tab, he already had six users and didn't want to annoy them by breaking compatibility with the makefiles they'd written :-)
> the (argh) Automake and Autoconf systems

The classic XKCD graph that plots life satisfaction against days-since-editing-xorg.conf could equally apply to days-since-thinking-about-autotools.

In fact one of the few times I've thought about autotools in the last decade was when a failing python-based build script inflicted similar frustration!

If I were forced to find one nice thing to say about autotools it would probably be that at least it doesn't assume an internet connection is always available, reliable and without cost.

It's is absolutely objectively true. Whether you already know it or not depends on your background