News for hackers. Stuff that matters.
Re:How We Use Make by bartbes on Friday April 03, 2015 @03:53PM (#9318010)
It's interesting how they list targets that have "practically become a convention", yet they're missing "all".

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

Re:How We Use Make by shazow on Friday April 03, 2015 @04:04PM (#9318101)
> 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.

Re:How We Use Make by exDM69 on Saturday April 04, 2015 @06:40AM (#9320507)
> 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 $@
Re:How We Use Make by bartbes on Friday April 03, 2015 @04:17PM (#9318203)
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.
Re:How We Use Make by shazow on Friday April 03, 2015 @04:26PM (#9318272)
¯\_(ツ)_/¯

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.

Re:How We Use Make by bartbes on Friday April 03, 2015 @04:32PM (#9318311)
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.
Re:How We Use Make by xyzzy_plugh on Friday April 03, 2015 @05:40PM (#9318746)
Why would you have `make all install' behave differently than `make install'? I'm imagining specifically when you have the install target present.
Re:How We Use Make by Leszek on Friday April 03, 2015 @08:28PM (#9319373)
Because `make all install` would first build, then install, while `make install` would just do the installation, regardless of build state.
Re:How We Use Make by wtallis on Friday April 03, 2015 @09:25PM (#9319513)
Wouldn't any sane install target depend on the build products it seeks to install, and consequently build before installing?
Re:How We Use Make by ianstormtaylor on Friday April 03, 2015 @09:16PM (#9319485)
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.

Re:How We Use Make by dominicbarnes on Friday April 03, 2015 @04:19PM (#9318216)
Haha, whoops must've lost those @ during editing. They've been restored :)
Re:How We Use Make by bartbes on Friday April 03, 2015 @04:27PM (#9318285)
Then I'd like to bring to your attention that you can have the @ come from a variable too, which means you can have conditionally silent files too. That always seemed to me like the perfect middle ground between silent compiles and knowing what's going on if things do fail.
Re:How We Use Make by groks on Friday April 03, 2015 @06:40PM (#9319014)

  $ man make | grep -A2 silent
       -s, --silent, --quiet
            Silent operation; do not print the commands as they are executed.