4 ms·

Bah. What's the harm here? It's not like you'll type make and then not be able to figure out what to do next. The problem you're trying to avoid when preserving

Bah. What's the harm here? It's not like you'll type make and then not be able to figure out what to do next. The problem you're trying to avoid when preserving default behavior is confusing the user, and that's not applicable here. Instead of blindly following laws like "Always meet user expectations" we should think about things in a case-by-case basis. Your law is at best a rule of thumb.

viraptor 11y ago
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.
- wfunction 11y ago
  One thing I don't quite know yet: how does 'make install' interact with package managers? Does it bypass them?
  - viraptor 11y ago
    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)
  - cyphar 11y ago
    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.
bschwindHN 11y ago
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.
- solipsism 11y ago
  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.
  - bschwindHN 11y ago
    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.
- ars 11y ago
  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.
  - vog 11y ago
    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.

viraptor 11y ago

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.

wfunction 11y ago
One thing I don't quite know yet: how does 'make install' interact with package managers? Does it bypass them?
- viraptor 11y ago
  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)
- cyphar 11y ago
  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.

bschwindHN 11y ago

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.

solipsism 11y ago
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.
- bschwindHN 11y ago
  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.
ars 11y ago
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.
- vog 11y ago
  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.