Hacker News Reader

Comment by yxlx | Hacker News Reader

>Wouldn’t it better if we could just type make, and get a list of available commands, together with their desciption?

No, Jesus Christ, please don't. Preserve default action as being to build.

Good user interface and good user experience relies on meeting expectations. This behavior breaks those expectations. What if your expectations are different, you ask? In environments where there is an established tradition I think it is rude to break with the norm unless there is a compelling reason to do so. The commandline is popular among developers, other IT professionals and power users because of how efficient it is. It is efficient because there is not all the noise, handholding and other bullsh*t. Please let us keep it that way.

Use a specific target to list other targets. I've seen some people use "make targets".

View on HN

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.

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.

"make help", as the Linux kernel does.

I agree, don't break the normal expectations, but they could've done much much worst.

This is basically how I've been doing for quite some time now. `make ?` Check it out here: https://github.com/gtramontina/sourcing/blob/master/Makefile...

If your users set failglob in their shells, they will have to type the less convenient "make '?'" or "make \?".

And regardless of whether they do or don't, if they are in a directory with a single character file name, they will have to escape it too...

I usually escape regardless... But you made a good point about the single character directory. The target name can be anything that makes sense, anyway... `make help` as suggested previously.

Then don't set the default target and keep using it as `make help`.

Or better, change the completion to should the description there when typing "make <tab>"

You could always alias make to the default you like. But if the newbie can't "make" it work, he/she gets frustrated.

I really wish dd had this type of caution. It would save me a lot of misery, preventing the loss of numerous drives.

Not sure it's a good habit for newbies to run arbitrary commands to see what they do. Asking for help somewhere (eg. `--help` flag) looks like a much better practice

"You could always alias make to the default you like"

That breaks down when you work with multiple projects.

For example, try writing a script that downloads and builds a couple of projects. You would have to parse each makefile and hope you can discover the right target to build.

"all" is the default target to build in GNU autotools projects.

    make all && sudo make install

"all" is also recommended default target in GNU make documentation:

Phony targets can have prerequisites. When one directory contains multiple programs, it is most convenient to describe all of the programs in one makefile ./Makefile. Since the target remade by default will be the first one in the makefile, it is common to make this a phony target named ‘all’ and give it, as prerequisites, all the individual programs.

Reply on news.ycombinator.com