Hacker News Reader

Comment by dahfizz | Hacker News Reader

One big reason I rely on Make: its old. Make has been well maintained for nearly 50 years, and is deeply integrated into the programming ecosystem as a whole.

I can start a new project that relies on Make, and be extremely confident that Make will continue to work and be maintained for the lifetime of my project. 20+ years from now, Make will still work. My Make knowledge will be relevant for my entire career.

New and shiny replacements like Just are tempting, but you have to consider the real cost of:

1) Learning a new build system

2) Onboarding new devs with an unfamiliar build system

3) Dealing with the eventual deprecation of the new shiny, once something newer and shinier comes out. Rewrite your build scripts, GOTO 1.

View on HN

I've yet to find a shiny replacement that is half as well thought out as make.

I'll look at Just, but is there anything else actually in make's space (scripting language agnostic, target language agnostic, auto parallelized, declarative, ergonomic syntax that is not xml, json, etc).

Many things claim to be a make replacement, but don't meet those basic requirements.

I've been working on a tool called Knit (https://github.com/zyedidia/knit) that I think is similar to what you are looking for. Essentially, a Knitfile is a Lua program with Make's declarative rule syntax baked in. Or in other words, it is like Make (with some additional changes inspired by Plan9 mk), but where Make's custom scripting language is replaced with Lua (but it still keeps the declarative rules language). It's still in progress (I'm currently using it in some projects, and then will likely make some more changes based on my experiences), but I hope to release a stable version in the next few months. If you or others also have feedback, please let me know!

There is nothing as general purpose as make because make already fills that space well. OTOH, there are special purpose replacements that do a much better job in their own domain.

eg: I wouldn't want to maintain a large Java project with make. Gradle has a lot of helpful built-ins for managing the complexity of subprojects/dependencies and also runs on the JVM which makes debugging for Java-programmers a little more in-reach than make.

All of that being said, I do use make for some fun personal projects. Automatic failure (a more-powerful "set -e" equivalent in common shells) and dependency tracking mean I can write really powerful automation scripts which can easily parallelize for slow steps.

I’ve been meaning to take redo[1] for a spin

[1]https://redo.readthedocs.io/en/latest/

Do note that GNU make is still being developed. It even had breaking changes in the recent 4.4 release. Also GNU make 4.3 has at least one bug (e.g. on Ubuntu 22.04) where

    tgt:
        gcc hello

errors when you have a directory with the name gcc in your PATH. (This is a bug in gnulib, that’s fixed, but gnulib is a rolling release typically vendored by every project on an arbitrary commit, sigh)

Also system GNU make on Ubuntu 20.04 has a bug in —-output-sync. It doesn’t sync.

And finally GNU make on macOS is ancient by default. Like over a decade old. So what works on Linux may not always work on macOS.

> Also GNU make 4.3 has at least one bug (e.g. on Ubuntu 22.04) where

> tgt:

> gcc hello

> errors when you have a directory with the name gcc in your PATH.

The make documentation examples use the CC variable to point to the path of the compiler. That is:

    CC=/usr/bin/gcc

Did the bug you mention also affect make files using variables to refer to the compiler program path in rule recipies?

Not sure what happens in the case of CC=gcc and $(CC) ..., but in any case, this is the bug:

https://savannah.gnu.org/bugs/index.php?57962

Good reasoning even through I never use it. Vim though I can see the same reasoning and that's why I use it :)

It's this old and yet it cant do the most basic of things. Wheres the switch to dump what it is executing and why? Why can't it time what it is doing? Why is it simultaneously so "simple" yet no workable alternative implementations exist?

It's honestly a terrible tool to use even at medium complex tasks.

-d

This seems like an example of not reading the manual and then blaming the tool.

The switch to dump what is executing is -d or --debug, the manpage has this listed in the list of flags you can pass, and they are even sorted alphabetically which means this is displayed near the top.

As for the time thing, it's not totally clear what you want, but you can probably just use the time command in the rule you want to measure. Most systems have an actual time command that is not a shell built-in at /usr/bin/time if for some reason the builtin doesn't work for this purpose.

Reply on news.ycombinator.com