Comment 1:

Labels changed: added priority-go1, removed priority-triage.

Comment 2:

go test needs to show output for passing tests, at least when there is only one package
being tested.

Comment 3 by rsc@swtch.com:

if go test is rebuilding stuff other than the package (because it is out of date) it
should print a warning so people know why it is slow

Comment 4:

Could we have the option, at least for "go installl", to toggle the
building/installation of standard library packages? 
The current iteration works well if I am on a privileged account or if I have write
access to both $GOROOT and $GOPATH, but If I have no write access to $GOROOT/pkg then
installing packages fails.
    ±! ganderson@excession [18:41:39] ../goconfig/config (master)                                                                                                                                 
    : echo $GOROOT && echo $GOPATH                                                                                                                                                                
    /usr/lib64/go                                                                                                                                                                                 
    /home/ganderson/go                                                                                                                                                                            
    ±! ganderson@excession [18:41:58] ../goconfig/config (master)                                                                                                                                 
    : go install                                                                                                                                                                                  
    open /usr/lib64/go/pkg/linux_amd64/sync/atomic.a: permission denied                                                                                                                           
    open /usr/lib64/go/pkg/linux_amd64/unicode.a: permission denied                                                                                                                               
    open /usr/lib64/go/pkg/linux_amd64/sort.a: permission denied
I had envisioned perhaps something like the following:
    The -s flag ommits installing packages from the standard library, if both -a and -s are passed, 
    the -a option supersedes the -s option.
Or perhaps no flag at all but allow the operation to continue and write the user package
into $GOPATH.

Comment 5:

My wish for this shiny tool: it should be able to build different sets of Go files per
arch/os. For example in my app (gocode) I use os_posix.go and os_win32.go files for OS
specific code. Goinstall can't handle that at the moment and this is the only thing that
stops me from making my app goinstallable.
Of course I can do that at runtime, but it should be done at compile-time.

Comment 6:

If you want to only build your file on windows, you should name it os_windows.go, not
os_win32.go. You could also use "// build ..." comment inside *.go file to specify os to
build it for. See source files in path/filepath package for a good example. All logic is
implemented in go/build package - see (*Context).shouldBuild and
(*Context).goodOSArchFile.
Alex

Comment 7:

Ah, thanks, Alex, I was looking for this functionality in cmd/go, didn't know about the
go/build package. Sorry then.

Comment 8 by tarmigan:

I like the new tool!
A feature request:
The only code-generation that I do is to embed version information into my binaries. 
(see https://groups.google.com/group/golang-dev/browse_thread/thread/0c50f73868f9525e ).
 This seems almost possible with the {{.Version}} information.  Could that {{.Version}}
be exposed to binaries in some way?
A few documentation suggestions:
From the one-line summary, 'build', 'get', and 'install' all sound nearly identical.  It
would be nice if the one-line summary helped distinguish between them better.  For
example do 'get' and 'install' not compile a program?  Build sounds like it installs a
command or package (though the long help suggests otherwise).
It would be nice if the long 'go help build' were indented.  As it is, it's hard to see
where in my terminal window that help text begins.

Comment 9:

Another small issue, I didn't find a way to use `cgo -godefs` using this tool (grep'ed
for 'godefs' in goinstall/go cmds and go/build package).
I have a nasty struct in my C bindings:
typedef struct {
    unsigned long        index;
    double               x;
    double               y;
} cairo_glyph_t;
unsigned long is 4 bytes on x86, 8 bytes on x86_64. Also wiki says: "A double (eight
bytes) will be 8-byte aligned on Windows and 4-byte aligned on Linux (8-byte with
-malign-double compile time option)", which is kind of scary.

Comment 10:

Hello
I did a quick test run with the go tool, but found it quite tricky to use on our project.
We have about 230 packages (about 10 packages use cgo) and 80 commands, totaling about
150k LOC.
We use protocol buffers (and had to resort to a bit of sed magic to hack the generated
code into a useful package structure). We also have a few commands for generating parts
of our code.
Our source tree looks like this:
potentially "public" packages:
src/pkg/foo/bar
src/pkg/baz
etc.
and our project package code:
src/pkg/ourproj/subsys1 (client API)
src/pkg/ourproj/subsys1/server (server code)
src/pkg/ourproj/subsys2
src/pkg/ourproj/subsys2/server
src/pkg/ourproj/subsys3
src/pkg/ourproj/subsys4
and our project commands:
src/cmd/group1/cmd1
src/cmd/group1/cmd2
src/cmd/group1/cmd3
src/cmd/group2/cmd4
src/cmd/group2/cmd5
src/cmd/group2/cmd6
which could maybe have been
src/cmd/ourproj/groupi/cmdj
but we wanted to save a bit of typing.
What makes the current assumed directory layout of the go tool (where everything is
mixed together) hard to use for us is that we have some overlap between
subsystem/package names, command names and the groups, so we have cases where
group_i==subsys_j or cmd_i==subsys_j. I suspect many big projects will run into this
when you start sharing common code via packages between many commands and
command-specific packages, and eventually the src directory becomes quite a mess.
The current src/{cmd,pkg} split which we modeled on the current Go tree has really
worked well for a very big project.
Another thing that would be very useful is just to be able to do:
git clone ourproj.git
export GOPATH=ourproj
cd ourproj
go install -a
but for some reason go doesn't understand about building an entire tree (except it seems
for Go itself, where you can say go install -a std). Typing 230 package names every time
is going to take a while.
That's all for now.
Cheers
Albert
P.S. Another great feature would be support for building with gccgo, as discussed here:
https://groups.google.com/group/golang-dev/browse_thread/thread/2c01e9d6e9b6b6a8

Comment 11 by mt4swm:

It may be the case that there are different projects that contain Go
programs with identical names. For instance, three projects
    DIR/src/github.com/project1/foo/bar/x.go  (go code in package main)
    DIR/src/github.com/project2/bar/y.go  (go code in package main)
    DIR/src/bar/z.go  (go code in package main)
(with DIR being part of GOPATH)
Running "go install" on any of the three program directories
will create binaries named DIR/bin/bar, i.e. all program
binaries will install to the same location.
1) A current workaround is to use a separate source hierarchy for
each project, i.e. DIR1, DIR2, DIR3 for the projects above,
listed in GOPATH.
2) Another way to cope with this situation would be to
replicate the structure of the DIR/src directory within
DIR/bin. The binary bar from project2 would be installed to
DIR/bin/github.com/project2/bar.
In a shell like Plan 9's rc it could be run at the prompt
directly as github.com/project2/bar, provided DIR/bin is in
the $PATH. With bash this is not possible as far as I know.
So perhaps that's not an option. It would require a modification
of the go tool resp. go/build.
3) Similarly, the binaries' names could be extended to contain a
translation of the project path, leading to the following names:
    DIR/bin/github.com-project1.com-foo-bar,
    DIR/bin/github.com-project2-bar,
    DIR/bin/bar.
4) Also, each project could try to create unique program names:
    DIR/src/github.com/project1/foo/foo-bar/x.go
    DIR/src/github.com/project2/y-bar/y.go
    DIR/src/z-bar/z.go
I would vote for 2), as it leaves no doubt about which binary
is to be run (and I'm mostly using rc), or 3).

Comment 12:

Owner changed to builder@golang.org.

Comment 13:

The go tool doesn't support building programs with goyacc (.y) source files.

Comment 14:

I wanted to build all the test binaries in the Go tree so that I could run each one
through 6cov, but
go test -c std
says:
cannot use -c flag with multiple packages
Seems like something that one might want to do...

Comment 15:

What should go test -c std do?
It cannot write 100 different tests
to a single output file.

Comment 16:

I was expecting that
go test -c std
would produce a 6.out in each package directory. I see the new go tool does stuff under
/tmp now, so maybe it breaks that plan...
Use case: with the current Go Makefiles, we compile all our packages and test binaries
in Jenkins, archive them as artifacts, and then we have other Jenkins jobs that farms
out the test binaries to separate machines that run them and see if they pass.
It's also nice to just be able to quickly check if all the tests in a big project build
(without running them... not all our machines even have the right hardware to run all
the tests) before you push a smallish fix to a repository.

Comment 17:

You can write an easy shell script to loop over
the output of $(go list std) and generate binaries
if that's what you need.

Comment 18:

Okay, sounds good. Will $(go list .) do the same for projects that aren't Go itself?

Comment 19:

Maybe it's time for a GoToolTricks wiki page, a la SliceTricks.

Comment 20:

Just 'go list'.

Comment 21:

I'm debugging a problem where I'd like to quickly see the difference between 6g and 6g
-N (i.e. I want to know if the optimizer is related to the problem I'm seeing). With
Makefiles, it would be easy to hack this, but a quick read of build.go seems to show
that there is no way to add additional args to the go compiler.
That should be possible.

Comment 22:

Also, at the end of "go help build" it mentions "go clean", but that doesn't seem to
exist.

Comment 23:

I find it quite confusing that when I do:
GOPATH= go build bork
an error is printed twice:
package could not be found locally
package could not be found locally
Is it looking in two other directories? At least it would be useful to know where it was
looking when it didn't find it.

Comment 24:

Another interesting double error that doesn't help is if you run "go build" without
parameters in the top level directory of your project:
$ (mkdir -p /tmp/foo ; cd /tmp/foo/; GOPATH=/tmp/foo go build)
path "/tmp/foo" not inside a GOPATH
path "/tmp/foo" not inside a GOPATH

Comment 25:

go list doesn't seem to work:
(mkdir -p /tmp/foo/src/bar; echo "package bar" > /tmp/foo/src/bar/bar.go && cd /tmp/foo
&& GOPATH=`pwd` go list)
path "/tmp/foo" not inside a GOPATH

Comment 26:

go install -v prints package names to stderr instead of stdout. Consequently, make.bash
>/dev/null stills spews a bunch of package names. They should probably go to stdout.

Comment 27 by mt4swm:

@25
You have provided an empty importpath, which would make the go subcommands (not only
list) look in the current directory (here: /tmp/foo) to examine the package probably
found there, but before actually getting that far, the go tool realizes that /tmp/foo is
not a subdirectory of /tmp/foo/src.
This works:
   ... && GOPATH=`pwd` go list bar
or
   ... && export GOPATH=`pwd` && cd src/bar && go list
or
   ... && GOPATH=`pwd` go list ./...

Comment 28:

I have a big project (250 packages, about 200 with tests), 100 commands.
I make a few code changes. Now I want to do a few things:
1. Compile all my packages
2. Compile all my packages and tests and run a few tests
3. Compile all my packages and commands and link the commands (if you have a large
number of commands, linking takes a while)
4. Run all package tests
5. Run all command tests
6. Commit my changes
The go tool seems to be missing a way to accomplish this kind of stuff when you're
sitting in the root of a large project where you can't remember all the package names.
With the old Makefiles I could do:
1. make -j16 -C src/pkg
2. make -j16 -C src/pkg test-compile && make -C src/pkg/foo/bar test
3. make -j16
4. make -C src/pkg test
5. make -C src/cmd test

Comment 29:

go install all
or
go install ./...  # just this subtree
go test all
go test ./...
go test ./foo/bar
go test import/path/for/foo/bar
go install ./cmd/...
Etc.

Comment 30:

I created issues 2799 and 2800 for comments #8 and #9.  I believe the other reported
issues have been addressed/have separate issues filed already.  If there is something
you reported that has not been addressed, please file a specific issue for it.  Thanks
for all the suggestions.

Status changed to Done.