Adds new GN template go_binary

Adds new GN template go_binary

This template supports the building of a Go binary, as opposed to a Go Mojo application. It optionally supports
the Go binary linking against native code using cgo.

I plan to use this to build the new version of the Mojom compiler
which is written in Go. This application needs to link against
the Mojo Go bindings because it will serialize the compiler's
intermediate representation to a Mojo message. This means that I need to use cgo and depend on the target
//mojo/public/platform/native:system.

Here is what my invocation looks like:

go_binary("mojom_parser") {
  sources = [
    "parser_main.go",
  ]
  inputs = [
    "generated/mojom_files/mojom_files.mojom.go",
    <some files elided from the list here>
    "parser/parsing.go",
  ]
  deps = [
    "//mojo/public/platform/native:system",
  ]
}

R=rogulenko@google.com, rogulenko

Committed: https://chromium.googlesource.com/external/mojo/+/226dddda4534a249db0133e17c57a7d6a1639bc9

[rudominer, 2015-09-30 23:13:57]

rudominer@chromium.org changed reviewers:
+ rogulenko@google.com

[rudominer, 2015-09-30 23:20:46]

Hi Sergey,

ptal

Mitch

[rogulenko, 2015-10-01 18:48:07]

https://codereview.chromium.org/1378993002/diff/1/mojo/go/rules.gni
File mojo/go/rules.gni (right):

https://codereview.chromium.org/1378993002/diff/1/mojo/go/rules.gni#newcode94
mojo/go/rules.gni:94: template("go_application") {
My high level question is how are you going to use it?
If you just want to simulate a normal 'go build ...' command, then you don't
need half of the stuff here: you don't need the static_library, the copy target
and the cgo stuff. I'm not sure if you need android. Also it would be nice to
get rid of the build_dir trick since the current version of the go tool supports
the -o flag.

[rudominer, 2015-10-02 16:36:00]

Thanks Sergey. I responded to your comments. Also I made the following changes:
- changed the name from go_application to go_binary
- made several arguments optional
- added an additional argument "inputs"
- added comments.

https://codereview.chromium.org/1378993002/diff/1/mojo/go/rules.gni
File mojo/go/rules.gni (right):

https://codereview.chromium.org/1378993002/diff/1/mojo/go/rules.gni#newcode94
mojo/go/rules.gni:94: template("go_application") {
On 2015/10/01 18:48:07, rogulenko wrote:
> My high level question is how are you going to use it?
> If you just want to simulate a normal 'go build ...' command, then you don't
> need half of the stuff here: 

I plan to use this to build the new version of the Mojom compiler
which is written in Go. This application needs to link against
the Mojo Go bindings because it will serialize the compiler's
intermediate representation to a Mojo message. This means that
I do need to use cgo and depend on the target
//mojo/public/platform/native:system.
(As an aside it should be possible to
refactor the Go bindings so that the native code is not
necessary for doing serialization. But that is a different
project.)

Here is what my invocation looks like:

go_binary("mojom_parser") {
  sources = [
    "parser_main.go",
  ]
  inputs = [
    "generated/mojom_files/mojom_files.mojom.go",
    <some files elided from the list here>
    "parser/parsing.go",
  ]
  deps = [
    "//mojo/public/platform/native:system",
  ]
}


you don't need the static_library, the copy target
> and the cgo stuff. I'm not sure if you need android. 
I got rid of Android support.

Also it would be nice to
> get rid of the build_dir trick since the current version of the go tool
supports
> the -o flag.

The current version of the go compiler checked into Mojo's third-party does not
yet support the -o flag. I have added a TODO to update the go compiler and then
simplify the rules in this file. I will do that in a follow up CL.

[rogulenko, 2015-10-02 18:32:25]

lgtm

OK, sounds good.
Thanks for the informative reply. I think it might be useful for someone else,
so could you put it into the CL description, please?

[rudominer, 2015-10-02 19:13:47]

On 2015/10/02 18:32:25, rogulenko wrote:
> lgtm
> 
> OK, sounds good.
> Thanks for the informative reply. I think it might be useful for someone else,
> so could you put it into the CL description, please?
done

[rudominer, 2015-10-02 19:14:45]

Committed patchset #2 (id:20001) manually as
226dddda4534a249db0133e17c57a7d6a1639bc9 (presubmit successful).