Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

cmd/go: inconsistent handling of package main importing another package main #5198

Closed
masiulaniec opened this issue Apr 3, 2013 · 8 comments
Milestone

Comments

@masiulaniec
Copy link

The spec seems to allow package main to import another package main under another name.
However, the experience with the go tool is inconsistent:

% cd $GOPATH/src/foo
% cat a/a.go
package main

import _ "foo/b"

func init() { println("init: a") }
func main() {}
% cat b/b.go
package main

func init() { println("init: b") }
func main() {}
% rm -f $GOPATH/bin/a
% rm -f $GOPATH/bin/b
% go install ./a
% touch a/a.go
% go install ./a
# foo/a
a/a.go:3: can't find import: "foo/b"
% 

My setup:

% go env
GOARCH="amd64"
GOBIN=""
GOCHAR="6"
GOEXE=""
GOGCCFLAGS="-g -O2 -fPIC -m64 -pthread -fno-common"
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOOS="darwin"
GOPATH="/p/go"
GOROOT="/usr/local/Cellar/go/1.0.3"
GOTOOLDIR="/usr/local/Cellar/go/1.0.3/pkg/tool/darwin_amd64"
CGO_ENABLED="1"
%
@adg
Copy link
Contributor

adg commented Apr 3, 2013

Comment 1:

The go tool assumes that a package main is an executable, and this is by design. The use
of "package main" is a signal to the go tool that you want to compile a command, not a
package object.
The spec allows importing another package main to allow for testing of package main. For
instance:
$ cat main.go 
package main
import "fmt"
func Hello() string {
    return "Hi"
}
func main() {
    fmt.Println(Hello())
}
$ cat main_test.go 
package main
import "testing"
func TestHello(t *testing.T) {
    want := "Hi"
    if got := Hello(); got != want {
        t.Errorf("Hello() = %q, want %q", got, want)
    }
}
Behind the scenes, when you run "go test", a new main package is constructed that
imports the package main that is under test.

Status changed to WorkingAsIntended.

@masiulaniec
Copy link
Author

Comment 2:

Okay, so maybe at the very least the go tool should reject such programs consistently. 
This scenario:
% go install ./a
% touch a/a.go
% go install ./a
# foo/a
a/a.go:3: can't find import: "foo/b"
% 
is surprising. The go tool should have either errored out on the first run, or succeed
on both; it should do something consistent. It feels buggy that a mere touch breaks the
build.

@davecheney
Copy link
Contributor

Comment 3:

I believe this is related to this issue,
https://golang.org/issue/3417.

@masiulaniec
Copy link
Author

Comment 4:

The WorkingAsIntended label seems invalid.

@adg
Copy link
Contributor

adg commented Apr 4, 2013

Comment 5:

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

Status changed to Accepted.

@rsc
Copy link
Contributor

rsc commented Jul 30, 2013

Comment 6:

Labels changed: added go1.2.

@rsc
Copy link
Contributor

rsc commented Jul 30, 2013

Comment 7:

Labels changed: added feature.

@robpike
Copy link
Contributor

robpike commented Aug 29, 2013

Comment 8:

Status changed to Duplicate.

Merged into issue #4210.

@rsc rsc added this to the Go1.2 milestone Apr 14, 2015
@rsc rsc removed the go1.2 label Apr 14, 2015
@golang golang locked and limited conversation to collaborators Jun 24, 2016
This issue was closed.
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

6 participants