There are few things more infuriating than a build tool that prompts for user input when it doesn't need to. Most people like to automate these things, and having a prompt ask for input after typing `make` is completely unexpected and annoying.

Bower is a particularly bad offender here. By default it will periodically ask you if it can send anonymous usage statistics. If you've never experienced it before, you have to angrily google the problem once piping `yes` to it fails and find a github issue where the solution is `bower install --config.interactive=false`

Always assume your build tool is running in an automated environment without user input. If the user wants to do something out of the ordinary, provide command line options and try to follow the conventions that already exist.

I agree 100% that a good build tool makes it easy to build in an automated context. But that's not relevant here, is it? make build is not less automatable than make. Sure, someone has to manually run make once to figure out what the actual build command is. But no person in his right mind would automate a build without running it manually once. I say this as someone whose job it used to be too automate builds.

Yeah you're right, you'd run it at least once locally and discover what the right command is. I guess I'm just letting my feelings for Bower permeate to other build tools, because sometimes it'll run without user input, and other times it will prompt for it.

It's not that hard to use the tty command to see if it's an interactive shell and set the config appropriately. Bower should do that automatically.

But this is yet another anti-pattern: Having different behaviour depending on whether it's an interactive shell or not.

A big offender here is CURL, where this affects the verbosity during download. This is especially frustrating with regard to automation.

1. You type by hand, everything works.

2. You copy&paste into the command line, and everything works.

3. You run it from a script, and it behaves differently.

One reason to leave it: It saves some writing / debugging for people doing system packaging. In debian the package build file (debian/rules) is reduced to two lines these days - as long as you don't mess with the standards. "configure && make && make install" is standard - if you go outside of that, someone will have to do extra work.

One thing I don't quite know yet: how does 'make install' interact with package managers? Does it bypass them?

Depends on what you mean by "interact". When you run it yourself, package managers don't matter. You're not interacting with them in any way (assuming it's a standard autotools/cmake/qmake/...-generated Makefile).

If you mean during packaging, then usually the code is configured with the actual destination path (configure --prefix=/usr), but then installed into a directory which will be packaged by overriding destination (make install DESTDIR=/tmp/some/path)

If you're talking about your local machine, it almost always does (and they rarely include `make uninstall` which is really annoying). As for creating packages, the way OBS (and I assume other packaging systems) work is that you `make install` into a temporary directory then figure out where things were installed and package those files.