Hacker News Reader

Comment by shazow | Hacker News Reader

> It's interesting how they list targets that have "practically become a convention", yet they're missing "all".

I think what he means is that their Makefiles effectively start having a common API across projects, by having similar target names.

No need to use "all" if you put the default target first (see `default` subsection in the post).

> I'm also intrigued by their claim they used @ in the recipes, yet they never did.

Yea seems that got stripped out.

Still, this is a good practical example for using a Makefile. I'm a fan of this too.

View on HN

> I think what he means is that their Makefiles effectively start having a common API across projects, by having similar target names.

> No need to use "all" if you put the default target first (see `default` subsection in the post).

That's obviously the reason they're doing that, but it's an odd decision. Especially since "all" is a common name for a Makefile target and .DEFAULT_GOAL can be used to override the "first target" convention of Makefiles.

    firsttarget: mysource.txt
        cp $< $@

    .DEFAULT_GOAL=all  # no need to put it first
    .PHONY: all
    all: firsttarget secondtarget

    secondtarget:
        touch $@

I realise their standard probably doesn't include all, but it seems like the obvious choice. Maybe I've just been conditioned by autotools, but I think it's standard practice to have all be your default target.

¯\_(ツ)_/¯

As long as running `make` does the Right Thing, does it matter if it does it via an `all` target or by defaulting to a different first target?

I do agree that generally `all` is a common convention, though.

It's really only relevant when specifying multiple targets, like 'make clean all', or the more common 'make all install'. It just seemed odd to me.

Why would you have `make all install' behave differently than `make install'? I'm imagining specifically when you have the install target present.

Because `make all install` would first build, then install, while `make install` would just do the installation, regardless of build state.

Why not have install do the build state, and then in most cases it wouldn't need to be run at all since the target would be up-to-date? Just curious.

I usually structure my targets so that I can run `make test` immediately without having to know what all the random commands are to build/install.

Wouldn't any sane install target depend on the build products it seeks to install, and consequently build before installing?

Reply on news.ycombinator.com