x/mobile: clean up broken packages (?)

[ip]

@crawshaw
That's not a big issue, but it is somewhat dirty and inconsistent. There are warnings (or errors?) particularly when getting these packages (perhaps there are more):
golang.org/x/exp/shiny/driver/gldriver golang.org/x/mobile/...

Please don't say that this is rare case and close the issue, because it is common form. When taking an import path with ..., go get will traverse all subpackages, so directories and files that doesn't contain go code should be named with starting underscore to avoid unnecessary warnings.
Example warnings:
..\src\golang.org\x\mobile\bind\java\testpkg\testpkg.go:19:2: no buildable Go source files in C:\Users\Vanya\Documents\PROG\Go\src\golang.org\x\mobile\asset ..\src\golang.org\x\mobile\exp\gl\glutil\glutil.go:12:2: C source files not allowed when not using cgo or SWIG: work.c can't load package: ..\src\golang.org\x\mobile\exp\gl\glutil\glutil.go:12:2: C source files not allowed when not using cgo or SWIG: work.c

Solution is for package maintainers to find all such cases and rename the folders and files.

[adg]

What is your environment? When I go get mobile/... I see legitimate errors for actually broken packages, but not those errors.

[ip]

@adg go version devel +fa87cf8 Wed Aug 19 04:36:55 2015 +0000 windows/amd64

[ip]

Generally for Windows I am periodically noticing some errors, such as test failures when building Go from recent Git revision, errors in /x/... packages telling that temporary folder can't be deleted because it is not empty (I think this is because slight difference in semantic of file API between Unix and Windows) and so on.
Possibly this is more general issue regarding testing infrastructure of Go development team.

[alexbrainman]

@ip I suspect the errors are from failed removals of temp files / directories. Windows won't allow you to remove opened files or directories that are current for any live process. Feel free to fix those. I would look in my %TEMP% directory, delete all files / directories there, then run all suspicious tests or build steps and see what is left in %TEMP%. This should give me some clues of where to look.

Alex

[gopherbot]

CL https://golang.org/cl/12970 mentions this issue.

[gopherbot]

CL https://golang.org/cl/13745 mentions this issue.