Improve build tooling

Improve build tooling

Some build targets - build, check, install and clean - can only run
when the tree is in the right place on GOPATH. The Makefile now guards
this and provides useful errors.

The system package dependencies are now more readably listed.

The ~juju PPAs are not added on Saucy; they do not work there.

A new clean target removes test executables and other detritus. *.test
files are also now ignored.

https://code.launchpad.net/~allenap/juju-core/makefile-stuff/+merge/181113

(do not edit description out of merge proposal)

[allenap, 2013-08-20 17:53:30]

Please take a look.

[allenap, 2013-08-21 08:20:09]

Please take a look.

[allenap, 2013-08-27 15:41:46]

Please take a look.

[rog, 2013-08-27 16:19:15]

LGTM but please wait for someone that's more familiar with GNU make syntax.

https://codereview.appspot.com/12949047/diff/7001/Makefile
File Makefile (right):

https://codereview.appspot.com/12949047/diff/7001/Makefile#newcode10
Makefile:10: PROJECT_DIR := $(shell go list -e -f '{{.Dir}}' $(PACKAGE))
Nice trick with -e there.

[jameinel, 2013-08-28 06:23:17]

Some comments, but overall LGTM

https://codereview.appspot.com/12949047/diff/7001/Makefile
File Makefile (right):

https://codereview.appspot.com/12949047/diff/7001/Makefile#newcode10
Makefile:10: PROJECT_DIR := $(shell go list -e -f '{{.Dir}}' $(PACKAGE))
You are using "PROJECT_DIR := .... $(PACKAGE)"

but I don't see where PACKAGE is getting set. Did you mean to use PROJECT there?

eg:
PROJECT_DIR := $(shell go list -e -f '{{.Dir}}' $(PROJECT))

https://codereview.appspot.com/12949047/diff/7001/Makefile#newcode44
Makefile:44: $(error Cannot build package outside of GOPATH)
This is really more of "you must be at $PROJECT_DIR to run build".
Which isn't strictly true from my experience.
You can run "go build launchpad.net/juju-core/..." and it will build everything
under there just fine. (I often use syntax similar to that when I'm in a subdir
and want to build something in a sibling dir.)

But given that Makefile is at the root, I don't think people will really do:
 make -f ../../../Makefile

anyway, so I don't think it is a big deal. So if it helps you to have the check
for CWD you can leave it in.

https://codereview.appspot.com/12949047/diff/7001/Makefile#newcode64
Makefile:64: gofmt -w -l -s .
Given that "time make format" and "time make simplify" doen't seem to differ, we
probably just want to always default to simplify.

So:

format: simplify

simplify:
  gofmt -w -l -s .

Though really *I* prefer

go fmt $(PROJECT)/...

Because that makes sure I get the files in another directory. (If I'm in the
subdir cmd/juju I'm probably also hacking on code in environs/tools or whatever)

Then again, Makefile isn't available easily in subdirs, so it doesn't matter
*for me*.

[allenap, 2013-08-28 11:54:22]

Thanks for the reviews, Roger & John.

https://codereview.appspot.com/12949047/diff/7001/Makefile
File Makefile (right):

https://codereview.appspot.com/12949047/diff/7001/Makefile#newcode10
Makefile:10: PROJECT_DIR := $(shell go list -e -f '{{.Dir}}' $(PACKAGE))
On 2013/08/28 06:23:17, jameinel wrote:
> You are using "PROJECT_DIR := .... $(PACKAGE)"
> 
> but I don't see where PACKAGE is getting set. Did you mean to use PROJECT
there?

Oh, embarrassing. `go list` does the right thing when in the project directory
on GOPATH so I didn't spot this. Fixed, thanks for spotting that.

https://codereview.appspot.com/12949047/diff/7001/Makefile#newcode44
Makefile:44: $(error Cannot build package outside of GOPATH)
On 2013/08/28 06:23:17, jameinel wrote:
> This is really more of "you must be at $PROJECT_DIR to run build".
> Which isn't strictly true from my experience.
> You can run "go build launchpad.net/juju-core/..." and it will build
everything
> under there just fine. (I often use syntax similar to that when I'm in a
subdir
> and want to build something in a sibling dir.)
> 
> But given that Makefile is at the root, I don't think people will really do:
>  make -f ../../../Makefile
> 
> anyway, so I don't think it is a big deal. So if it helps you to have the
check
> for CWD you can leave it in.

I think it's good to keep it. For example, if someone runs `make build` from a
tree that's not on GOPATH it will build a different tree (assuming one exists)
that is on GOPATH, and it'll get confusing. I'll change the message though, to
something like "Cannot build; $(CURDIR) is not found in GOPATH". I think that
better explains what's happening.

https://codereview.appspot.com/12949047/diff/7001/Makefile#newcode64
Makefile:64: gofmt -w -l -s .
On 2013/08/28 06:23:17, jameinel wrote:
> Given that "time make format" and "time make simplify" doen't seem to differ,
we
> probably just want to always default to simplify.
> 
> So:
> 
> format: simplify
> 
> simplify:
>   gofmt -w -l -s .

Okay, I'll do that.

> 
> Though really *I* prefer
> 
> go fmt $(PROJECT)/...
> 
> Because that makes sure I get the files in another directory. (If I'm in the
> subdir cmd/juju I'm probably also hacking on code in environs/tools or
whatever)
> 
> Then again, Makefile isn't available easily in subdirs, so it doesn't matter
> *for me*.

Instead of using `make -f ../../Makefile format` you can use `make -C ../..
format` which will DTRT for you, and is shorter.

[rog, 2013-08-28 14:50:10]

https://codereview.appspot.com/12949047/diff/7001/Makefile
File Makefile (right):

https://codereview.appspot.com/12949047/diff/7001/Makefile#newcode64
Makefile:64: gofmt -w -l -s .
On 2013/08/28 11:54:23, allenap wrote:
> On 2013/08/28 06:23:17, jameinel wrote:
> > Given that "time make format" and "time make simplify" doen't seem to
differ,
> we
> > probably just want to always default to simplify.
> > 
> > So:
> > 
> > format: simplify
> > 
> > simplify:
> >   gofmt -w -l -s .
> 
> Okay, I'll do that.

I'm not sure that we should always run simplify.
I think that format should mean just exactly gofmt;
"simplify" is a step further and should only be
done with a watchful eye, IMHO.

[allenap, 2013-08-28 20:13:45]

Please take a look.

[allenap, 2013-08-28 20:18:10]

Sigh.

[allenap, 2013-08-28 21:11:00]

LGTM self-review.