Thanks for the clarification and the advice. Seems that what we need to do is make sure that these key tools are installed from source in the makefile, or provide a script that installs them as a post-go-upgrade step in our instructions. Will experiment with those to see which works best for us.
On Thursday, 15 September 2016 17:22:27 UTC-4, Dave Cheney wrote: > > ok, that sounds like a different problem. Some tools use the cached (.a > file in the pkg/ directory) version others use the src directly. If you > don't install, the tools that use the .a version will be out of date (at > best) or fail (at worse). > > Really, you want to use go install, just trust me on this, it'll make you > go experience much better all round. > > On Friday, 16 September 2016 04:03:54 UTC+10, Tom Elliott wrote: >> >> Thanks for the quick response :) >> >> Great to hear that the go tool is intended to catch this. The problem was >> typically seen when running our default make target, which uses build for >> the build itself, but has some sanity checking and code generation steps >> first, with tools like glock, errcheck and mockgen. >> I think that most failures were in this first phase. Could it be possible >> that we hit this as a result of usage of the ast package or importgraph >> within these tools? If so, clearing the pkg directory may have been a red >> herring. >> >> I can try to reproduce this later this evening and see if I can pin down >> the exact culprit. >> > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
