How to join a team and learn a codebase (2020)

- 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...

But I think this one point is the one item that ultimately decides on the lifetime of a project and whether it will turn legacy. If the README doesn't even describe how to start the project or successfully invoke a single unit test, how is anyone going to deploy this or change anything of the core code? Also not having this usually means unreliable deployments, broken CIs and constant firefighting. This might be considered acceptable for 1-person-projects until that one person might change projects or jobs.

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 :(

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.