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.
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.
On Mon, May 7, 2012 at 10:20 AM, Bill Thiede wrote:
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?
On Monday, May 7, 2012 1:36:10 AM UTC-7, David Symonds wrote:
On Mon, May 7, 2012 at 3:05 PM, Bill Thiede 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.