how does go install know what to bin?

[tran...@gmail.com]

Since project's seem to have so much variation is their layouts --some examples:

      foo.go  <- main
      src/
        foo.go


      foo.go
      foo/
        foo.go  <- main


      foo.go
      bin/
        foo.go  <- main


      pkg/
        foo/
          foo.go
      cmd/
        foo/
          foo.go  <- main


And so on. With all this variation, how does `go install` know what to compile as the binary to put in the workspace's bin directory?

[Dave Cheney]

Packages who's package declaration is main are Commands. Commands are
compiled and linked as binaries and placed in $GOPATH/bin (or GOBIN if
set).

Cheers

Dave

> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.

[TR NS]

On Tuesday, November 5, 2013 6:34:37 AM UTC-5, Dave Cheney wrote:

Packages who's package declaration is main are Commands. Commands are
compiled and linked as binaries and placed in $GOPATH/bin (or GOBIN if
set).

Ok. This is what I am trying to understand. So it literally searches through all the *.go files in a project and makes anything with `package main` a bin. Is that correct?

[Dave Cheney]

That is orthogonal

If you did go install ... (literally ...) then anything that is a
Command in your $GOPATH will be compiled and it's binary placed into
$GOPATH/bin. The name of the binary will be the directory the Command
is found in.

http://golang.org/doc/code.html#Command

[TR NS]

On Tuesday, November 5, 2013 6:44:04 AM UTC-5, Dave Cheney wrote:

That is orthogonal

If you did go install ... (literally ...) then anything that is a
Command in your $GOPATH will be compiled and it's binary placed into
$GOPATH/bin. The name of the binary will be the directory the Command
is found in.

http://golang.org/doc/code.html#Command

I don't understand how it is "orthogonal". You say "anything that is a Command", but what is it to be a Command?

One of the things I am wondering about with this... is there no way to keep a scrap go file around (that has `package main`) in it? e.g. lets say I want to keep such a file for reference sake, so I drop it in a `scrap` directory. Bit it would seem this might be a problem b/c it will still get turned into a executable even though it is only in my project for reference sake.

I should also add `go get` to this question. One of the things I am trying to understand too, when one does a `go get` I assume it installs the dependencies and compiles the "Commands" of those dependencies just as it does with `go install`. Correct?

[Martin Schnabel]

On 11/05/2013 01:03 PM, TR NS wrote:
>
> I don't understand how it is "orthogonal". You say "anything that is a
> Command", but what is it to be a Command?

http://golang.org/doc/code.html#PackageNames
"Executable commands must always use package main."

>
> One of the things I am wondering about with this... is there no way to
> keep a scrap go file around (that has `package main`) in it? e.g. lets
> say I want to keep such a file for reference sake, so I drop it in a
> `scrap` directory. Bit it would seem this might be a problem b/c it will
> still get turned into a executable even though it is only in my project
> for reference sake.

just prefix the folder name with an underscore "_scrap".
from $ go help packages
"File names that begin with "." or "_" are ignored by the go tool."

[TR NS]

Very helpful info. Thank you.

[Andrew Gerrand]

On 6 November 2013 00:43, Martin Schnabel <m...@mb0.org> wrote:

just prefix the folder name with an underscore "_scrap".
from $ go help packages
"File names that begin with "." or "_" are ignored by the go tool."

Another approach is to add

// +build ignore

to the top of the file. This will prevent it from being built. (Unless you run "go install -tags ignore", but why would you do that? :-)

Andrew