Hacker News Reader

Comment by muskox2 | Hacker News Reader

- Make is a standard utility, so anyone that has used make before will know what 'make', 'make clean', etc will do without having to read any documentation.

- Make has the ability built-in to only run certain commands based on the files that have changed, which can be handy.

- Makefiles usually have a lot of handy variables for configuring the project like $CC or $DESTDIR. While you could have these in a bash script as well, there's a standard convention for variables in Make[1].

In my experience, Makefiles are usually better documented and follow more conventions than scripts. There are of course many exceptions to every rule.

Make files are very similar to bash scripts, and while I would prefer a Makefile any day, it's really a matter of preference.

[1]: https://www.gnu.org/prep/standards/html_node/Makefile-Conven...

View on HN

I think we also need to be careful. The OP on this thread did not specify what kind of project. Make may be completely appropriate. It might also not be and just what they are used to. The proverbial hammer.

If someone came in and tried to build my Java project with Make, I would definitely call them crazy and not use it either. If someone came to my Java project and tried to put Gradle on it to build it, I might also not use it but at least its appropriate for the language and if everyone on the team/project was OK with it, I would probably be OK with it and use it.

If someone tried to build my FE Javascript project with Make, I would not use it. If they used yarn instead of npm that would be a Gradle vs. Maven situation as above, so either's fine if there's nothing yet.

If there's a set of bash scripts that are perfectly adequate to build the project you have, fine, why use Make?

And let me tell you from experience, conventions are great but don't always work, i.e. no $CC and $DESTDIR are definitely not something every user of Make does appropriately. I've had to add that to a few back in the day. You install like you're used to with DESTDIR only to find that it just installed itself into your system. You swear, fix it and learn to _always_ check a newly downloaded project for whether they actually have the 'standard' features implemented before you build something.

Contrast that with many of the newer build and packaging tools, that basically take this choice away from the user, which is a great thing if you ask me. Sure you have to get over the "but I want to do it my way" defiance reaction but in the end it is awesome when each new project you come to you do _not_ have to check and learn how exactly that project does things because every Maven project has its stuff in the same place (unless someone re-configured it, which unfortunately does happen). But maven is bad nowadays, coz it uses XML :(

This was a Node, Rails and-then-some project.

Rails comes with Rake, the Ruby make. Node comes with 'scripts' and then gulp, grunt, or whatever the node-js-buildsystem of january 2021 is. 'and then some' is a bash script or four, custom rake tasks, bash-scripts+follow-some-wiki and so on.

Make's other great advantage is that it makes a great 'overarching' general setup. Whether I have a rails, node, ansible, cargo/rust, jekyll-project, `make install` installs it, `make [build]` builds it, `make test` tests it and `make deploy` deploys it. It solves the "yea, but here you need npx" and "this will only work with bundle exec prefixed" or "you have to run this with `python2` as `python` is python 3 and... We all know these cases.

Edit: or, in your examples: `JAVA_HOME="." maven build` is fine. As is `PDF_BUILD=true maven run test {integration,unit,model,jobs}` already less so (I don't know much about maven). All require the dev to know how to operate maven, to learn that this project uses maven and to know the intricacies of maven. But they could all be abstracted away beind one predictable `make build` and `make test`; and whould therefore work for your maven project, node project, that ancient ant-setup and whatnot: all the same (well, if they all have a Makefile, that is).

You seem to be assuming that people know make. People don't any longer. People that grew up with C, built their Linux system from scratch etc. know Make. For someone that doesn't know make, none of what you say comes natural or 'makes sense'.

Also, make is a very general purpose tool. You don't have to have a `test` target. I could easily call the target `analyze`. Do you store your compiled files in a `dist` folder? Or do they just end up right next to the source files? Where are your test files stored vs. your main project files?

In the Java world the equivalent of Make would have been ant at some point. People did exactly what you said you would do with make. Most people had the default ant run build the project, test would test it etc. but everything else was a complete free for all.

What Maven did was standardize a lot. The test goal (goal being maven speak for make targets) is always called test. All build output always goes to the `target` folder. maven always expects your test files nicely out of the way of regular source files and they never end up in the resulting package etc. The package(s) always end up in the target folder too. Most if not all of these things can actually be changed but it's work to do it and you can easily see it being reconfigured vs. build tools like Make or Ant, which are much more general purpose like shell scripts.

I could make the same assertions about maven btw. as you do about Make. Once you know maven, you can build anything you like with it and it takes care of all of the same things. In a previous life we actually regularly packaged non-java projects with maven, since that was the hammer we had and understood.

Reply on news.ycombinator.com