Is the SDK building and vetting files in package main?

93 views
Skip to first unread message

Bill Thiede

unread,
May 7, 2012, 1:05:17 AM5/7/12
to google-ap...@googlegroups.com
I know the solution for GOPATH is still in the works, so in the mean time, I'm trying to get the same affect by checking out packages into the appropriate directories under my app.  I'm trying to use the freetype library available at:


So in my source directory I did:


Now when I try to load my app I get:

2012/05/06 21:41:36 go-app-builder: Failed parsing input (1 error)
2012/05/06 21:41:36 /path/to/myapp/code.google.com/p/freetype-go/example/round/main.go:36:28: composite struct literal image.Uniform with untagged fields

Which is weird for a few reasons:
0. I'm not including main.go, nor is any of my dependencies.
1. main.go is in package main and I would think app engine would have no reason to compile anything in package main, heck _my_ program isn't even in a package main

2. It's not actually a compilation error on the commandline:
$ go run main.go
Wrote out.png OK.
$

3. It seems a problem if I run 'go vet' although it's not the same error message I get from the SDK: 
$ go vet main.go 
main.go:36:28: image.Uniform struct literal uses untagged fields
main.go:44:8: code.google.com/p/freetype-go/freetype/raster.Point struct literal uses untagged fields
main.go:48:8: code.google.com/p/freetype-go/freetype/raster.Point struct literal uses untagged fields
main.go:52:16: code.google.com/p/freetype-go/freetype/raster.Point struct literal uses untagged fields
main.go:53:16: code.google.com/p/freetype-go/freetype/raster.Point struct literal uses untagged fields
main.go:53:43: code.google.com/p/freetype-go/freetype/raster.Point struct literal uses untagged fields
main.go:54:16: code.google.com/p/freetype-go/freetype/raster.Point struct literal uses untagged fields
main.go:54:43: code.google.com/p/freetype-go/freetype/raster.Point struct literal uses untagged fields
main.go:58:22: code.google.com/p/freetype-go/freetype/raster.Point struct literal uses untagged fields
main.go:60:16: code.google.com/p/freetype-go/freetype/raster.Point struct literal uses untagged fields

One last data point, not sure if it matters:
$ go version
go version go1.0.1

Should I file a bug about this somewhere? or am I trying to put a round peg in a square hole?  

Bill

David Symonds

unread,
May 7, 2012, 4:36:10 AM5/7/12
to Bill Thiede, google-ap...@googlegroups.com
On Mon, May 7, 2012 at 3:05 PM, Bill Thiede <couch...@gmail.com> wrote:

> or am I trying to put a round peg in a square hole?

Right now, yes. You probably just want to remove that subdirectory
from your app entirely.


Dave.

Bill Thiede

unread,
May 7, 2012, 1:20:51 PM5/7/12
to google-ap...@googlegroups.com
Is the compilation of main packages expected behavior?  Could this be 'fixed' by excluding main packages from the build process?  That seems like a potentially small tweak that could happen independent of 'solving' the GOPATH problem, although it would probably be necessary for proper GOPATH support too.  

Also, can you explain why the untagged fields message is an error with the appengine SDK but not a problem with the standard Go?  Are there more differences like this between the two environments, and is it documented somewhere?

Thanks,
Bill

On Monday, May 7, 2012 1:36:10 AM UTC-7, David Symonds wrote:

Kyle Lemons

unread,
May 7, 2012, 1:36:46 PM5/7/12
to Bill Thiede, google-ap...@googlegroups.com
=I think this would mask the problem: if there is an unimported package (even if it's not main) that registers an HTTP handler in an init(), then that will become a part of your app.  I would carefully include only the packages you import to avoid this sort of debugging headache.

Bill Thiede

unread,
May 7, 2012, 2:05:38 PM5/7/12
to google-ap...@googlegroups.com, Bill Thiede
Good point.  I actually had this problem with my own source that was in package main, I was able to fix the problem in source I owned by using:

// +build !appengine

But I was looking for a way to solve this for third parties without having to edit their code.

Can I have appengine only build code I include then? :) I'm surprised it works so differently than the standard go tools in this regard, although I can imagine appengine doing all sorts of magic, so I'm not going to trivialize by speculating that's an easy fix. 

I would be interested in knowing why it does this, as more of an academic interest.

Bill


On Monday, May 7, 2012 10:36:46 AM UTC-7, Kyle Lemons wrote:
=I think this would mask the problem: if there is an unimported package (even if it's not main) that registers an HTTP handler in an init(), then that will become a part of your app.  I would carefully include only the packages you import to avoid this sort of debugging headache.

David Symonds

unread,
May 7, 2012, 6:59:14 PM5/7/12
to Bill Thiede, google-ap...@googlegroups.com
On Tue, May 8, 2012 at 4:05 AM, Bill Thiede <couch...@gmail.com> wrote:

> Can I have appengine only build code I include then? :) I'm surprised it
> works so differently than the standard go tools in this regard, although I
> can imagine appengine doing all sorts of magic, so I'm not going to
> trivialize by speculating that's an easy fix.

We will eventually get to that point, but we're not there yet. Right
now, any code in your app's directory will be built, except for files
excluded by the "// +build" tags and files named *_test.go.


Dave.

Stephen

unread,
May 7, 2012, 8:06:10 PM5/7/12
to google-ap...@googlegroups.com
Reply all
Reply to author
Forward
0 new messages