Go build command

[kevin]

I've recently returned to Go, and am happy with almost all of the new
changes. The only one that I'm having trouble with is the "go command"
program that is now used to build packages. I wrote this in test.go:

package test
import("fmt")
func main() {
fmt.Println("working")
}

Next I ran:
$ go build -o test test.go

And then nothing happened. Nothing was printed to stdout, and the exit
code was 0. But my package did not get built as far as I can tell. I
was expecting it to appear in the current directory. I've read the
documentation here: http://golang.org/cmd/go/. What am I doing wrong?

The next thing I tried was
$ go install test.go
go install: no install location for command-line-arguments

What are command-line-arguments? That's not a Go package as far as I
can tell, and test.go is definitely not using any command line
arguments.

Here's my go env:
GOROOT="/home/kevin/go"
GOBIN="/home/kevin/go/bin"
GOARCH="amd64"
GOCHAR="6"
GOOS="linux"
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOTOOLDIR="/home/kevin/go/pkg/tool/linux_amd64"
GOGCCFLAGS="-g -O2 -fPIC -m64 -pthread"
CGO_ENABLED="1"

and $GOPATH, where test.go is in /home/kevin/goproj1:
/home/kevin/go/:/home/kevin/goproj1/

I'm probably making a stupid mistake. However, I'm someone who has
spent a considerable amount of time programming in Go. I imagine that
many beginners are making the same mistakes I am. Perhaps something
can be done to make it easier to figure out this process. At least
with the old makefile system for Go, we used to be able to see
feedback about what our errors were.

[Peter Bourgon]

Your GOPATH needs to point to a directory that contains a "src"
subdirectory. (None of the other environment variables are necessary;
you would probably do well to remove them, so as to eliminate
potential sources of confusion.)

Your test program needs to reside somewhere underneath that "src"
subdirectory; probably, in "src/test".

In order for your source files to produce a binary, it must be
"package main", not "package <anything-else>". "main" produces a
binary, anything else produces a library (.a).

Then, you can use the go tool to produce build artifacts. My
understanding of each of the go verbs follows:

src/test$ go build . # produces binary in current dir
src/test$ go install . # produces binary in $GOPATH/bin
src/test$ go get . # same as 'install' but resolves import deps

Note that (1) the go tool operates on "package" nouns (the '.') and
not files directly; and (2) unless you specify -o, the name of the
build artifact is deduced from the name of the _folder_ that holds the
code, not the name of the .go file.

I hope this has been helpful. If I've said anything incorrect I hope
someone will correct me.

[John Asmuth]

On Monday, April 30, 2012 3:00:45 PM UTC-4, kevin wrote:

And then nothing happened. Nothing was printed to stdout, and the exit
code was 0. But my package did not get built as far as I can tell. I
was expecting it to appear in the current directory. I've read the
documentation here: http://golang.org/cmd/go/. What am I doing wrong?

Commands must get a package "main". If you give it something other than "main", it's considered a package rather than an executable binary. I you "go build" a package, it will test to make sure it compiles, but it won't install it anywhere.

 

The next thing I tried was
$ go install test.go
go install: no install location for command-line-arguments 

What are command-line-arguments? That's not a Go package as far as I
can tell, and test.go is definitely not using any command line
arguments.

The "command-line-arguments" being referred to are the "test.go" arguments you provided to "go install". "go install" only works with things in GOPATH ("go help gopath" on the command line for details).

 

[andrey mirtchovski]

> Your GOPATH needs to point to a directory that contains a "src"
> subdirectory. (None of the other environment variables are necessary;
> you would probably do well to remove them, so as to eliminate
> potential sources of confusion.)
>
> Your test program needs to reside somewhere underneath that "src"
> subdirectory; probably, in "src/test".

as an addition to this, note that when using 'go build' neither GOPATH
nor 'src' are required for simple binaries. this is very useful for
testing one-offs like the OP's.

$ mkdir /tmp/test
$ cd /tmp/test
$ cat > test.go
package main

import("fmt")
func main() {
fmt.Println("working")
}

$ echo $GOPATH
$ go build ./
$ ls -l
total 2352
-rwxr-xr-x 1 a wheel 1196048 Apr 30 13:20 test
-rw-r--r-- 1 a wheel 73 Apr 30 13:19 test.go
$ rm test
$ go build test.go
$ ls -l
total 2352
-rwxr-xr-x 1 a wheel 1196048 Apr 30 13:20 test
-rw-r--r-- 1 a wheel 73 Apr 30 13:19 test.go
$

[kevin]

I was trying to build a library, so it "go install" was the
appropriate command for me. I realize test.go was more of a command
than a library, but I was trying to get the process to work for test,
so I could repeat it for other libraries I'm trying to build.

I changed the directory structure so that it looks like this:
GOPATH=/home/kevin/go/:/home/kevin/goproj1

/home/kevin/goproj1
src/
test/
test.go

Then I was able to run:
$ cd /home/kevin/goproj1
$ go install test

I didn't realize how strict the directory structure was from reading
"How to Write Go Code" the first time. But looking back at the
article, all the information was there.
Thanks for the help.

[André Moraes]

On Mon, Apr 30, 2012 at 4:39 PM, kevin <kevi...@gmail.com> wrote:
> I was trying to build a library, so it "go install" was the
> appropriate command for me. I realize test.go was more of a command

You don't need to goinstall your library.

Most of the time, go build ./... solves the problem, in fact recently
I just used go install to install commands not libraries.

Also, don't forget the "go get" which is the equivalent of the old goinstall.
The current "go install" only works for "local" packages, you must "go
get" them first.

--
André Moraes
http://andredevchannel.blogspot.com/

[Peter Bourgon]

> Also, don't forget the "go get" which is the equivalent of the old goinstall.
> The current "go install" only works for "local" packages, you must "go
> get" them first.

First, or instead? It's my understanding that "go get X" implicitly
does a "go install X" after downloading X to the appropriate location.

[André Moraes]

Maybe the user changed something in the local download of a package,
in that case,
he must call "go install" instead of "go get".

Also, my intention was to altert that "go install" only work on local
packages and
go get works on remote.

--
André Moraes
http://amoraes.info