code review 84040045: cmd/dist: reflect local changes to tree in goversion

cmd/dist: reflect local changes to tree in goversion

runtime.Version() requires a trailing "+" when
tree had local modifications at time of build.

Fixes issue 7701

[mra, 2014-04-03 17:02:15]

Hello golang-codereviews@googlegroups.com,

I'd like you to review this change to
https://code.google.com/p/go

[iant, 2014-04-03 23:28:20]

LGTM

[iant, 2014-04-03 23:31:45]

*** Submitted as https://code.google.com/p/go/source/detail?r=5302b4c58aa0 ***

cmd/dist: reflect local changes to tree in goversion

runtime.Version() requires a trailing "+" when
tree had local modifications at time of build.

Fixes issue 7701

LGTM=iant
R=golang-codereviews, iant
CC=golang-codereviews
https://codereview.appspot.com/84040045

Committer: Ian Lance Taylor <iant@golang.org>

[gobot, 2014-04-04 00:47:23]

This CL appears to have broken the plan9-386-cnielsen builder.
See http://build.golang.org/log/9fd7655590b0aadfd24f14c438e6a5e5a6e79a2a

[mra, 2014-04-04 00:54:10]

to me it looks like essentially the same errors we saw earlier today
on 8dfa08f77593, several commits back? so maybe it's a buggy builder per se?

i.e., these two error reports look pretty similar to me:

http://build.golang.org/log/e64d8d63ea855abd19f1ea49b5939a74cadd601b

and

http://build.golang.org/log/f2691780d6b506d25d577ce5350b15a0dc441705

best,
mike



On Thu, Apr 3, 2014 at 8:47 PM, <gobot@golang.org> wrote:

> This CL appears to have broken the plan9-386-cnielsen builder.
> See http://build.golang.org/log/9fd7655590b0aadfd24f14c438e6a5e5a6e79a2a
>
> https://codereview.appspot.com/84040045/
>

[iant, 2014-04-04 02:00:29]

On Thu, Apr 3, 2014 at 5:53 PM, Mike Andrews <mra@xoba.com> wrote:
>
> to me it looks like essentially the same errors we saw earlier today on
> 8dfa08f77593, several commits back? so maybe it's a buggy builder per se?

It's unrelated to this CL.

Ian

[minux1, 2014-05-17 21:38:02]

now i think we should take the other route and fix the runtime docs instead (the
docs has been wrong since Go 1.0)

i just faced exactly the situation rsc used to reject this very idea 2 years
ago. (a single change in the tree when building the compiler will render all
object files stale)

see last comment of CL 5731059 for rsc's comment.

I created CL 100520043 and CL 94560043 for this.

[mra, 2014-05-17 22:27:31]

On 2014/05/17 21:38:02, minux wrote:
> now i think we should take the other route and fix the runtime docs instead
(the
> docs has been wrong since Go 1.0)
> 
> i just faced exactly the situation rsc used to reject this very idea 2 years
> ago. (a single change in the tree when building the compiler will render all
> object files stale)
> 
> see last comment of CL 5731059 for rsc's comment.
> 
> I created CL 100520043 and CL 94560043 for this.

makes sense to me, thanks for revisiting.

-mike