unicode/utf16 tests does not compile when copied outside $GOROOT

[Elazar Leibovich]

Here is what I get on Mac OS X

❯ go version

go version go1.0.2

❯ (cp -r $GOROOT/src/pkg/unicode/utf16 /tmp; cd /tmp/utf16; go test; rm -rf /tmp/utf16) 

# _/tmp/utf16_test

./utf16_test.go:16: undefined: MaxRune

./utf16_test.go:17: undefined: MaxRune

./utf16_test.go:19: undefined: ReplacementChar

./utf16_test.go:20: undefined: ReplacementChar

FAIL _/tmp/utf16 [build failed]

❯ (cd $GOROOT/src/pkg/unicode/utf16; go test)

PASS

ok   unicode/utf16 0.022s

Also happens with 1.1beta: go version devel +267bb9854177 Wed Apr 03 18:23:43 2013 -0700 darwin/amd64

I don't understand how is that even possible. It looks like export_test.go isn't included in the test build for some reason.

Is it expected? If not, can you try and recreate it?

If it is, why?

Thanks,

[Jan Mercl]

On Tue, Apr 30, 2013 at 7:31 PM, Elazar Leibovich <ela...@gmail.com> wrote:

IIRC, the Go build system doesn't (or didn't in 1.0.2) support
úackages outside $GOPATH (i.e. it's not related to being outside
$GOROOT).

-j

[Elazar Leibovich]

Good point.
I forgot to mention, it also happens when utf16 is in GOPATH

~GOPATH/src/utf16❯ pwd
/Users/eleibovi/gopath/src/utf16
~GOPATH/src/utf16❯ echo $GOPATH
/Users/eleibovi/gopath
~GOPATH/src/utf16❯ go build
~GOPATH/src/utf16❯ go test
# utf16_test

./utf16_test.go:16: undefined: MaxRune
./utf16_test.go:17: undefined: MaxRune
./utf16_test.go:19: undefined: ReplacementChar
./utf16_test.go:20: undefined: ReplacementChar

FAIL utf16 [build failed]

If anyone can try it on other machines and let us know how is the
behaviour, that would be great.

[Andrew Gerrand]

A few things are going on here.

The file utf16_test.go is in package utf16_test and dot-imports the package "unicode/utf16".

The file export_test.go is in package utf16 and contains two exported constants. Its purpose is to give the aforementioned test file access to these internal constants during testing only. The export_test.go file is only compiled into the utf16 package when it is being tested, otherwise those exported constants are not visible to users of the utf16 package.

To fix this, change the dot import in your copy of utf16_test.go to reflect the location of your copy of the package.

Andrew 

[Elazar Leibovich]

Thanks!

The confusing bit here (at least for me), is that in test builds, writing:

    $ head -n2 my_test.go

    package mypkg_test

    import "mypkg"

is not the same as writing `import "mypkg"` in a different package. I figured both would use the same .a, so I thought importing the original unicode/utf16 wouldn't matter.

BTW, is there any benefit for using this trick? If you want to poke into the package internals, why won't you just use `package utf16` in your test files?

[minux]

On Wednesday, May 1, 2013, Elazar Leibovich wrote:

Thanks!

The confusing bit here (at least for me), is that in test builds, writing:

    $ head -n2 my_test.go

    package mypkg_test

    import "mypkg"

is not the same as writing `import "mypkg"` in a different package. I figured both would use the same .a, so I thought importing the original unicode/utf16 wouldn't matter.

BTW, is there any benefit for using this trick? If you want to poke into the package internals, why won't you just use `package utf16` in your test files?

then you can't import any package that directly or

indirectly depends on unicode/utf16 in the tests

or you will create circular imports.

as unicode/utf16 is pretty low level, and windows

syscall package depends on it, you have to put its

test into another package, or you won't be able to

even import testing,