Update Go Portfile to 1.2

[b@…]

Go 1.2 is officially released: ​http://blog.golang.org/go12 Go 1.2 fixes several bugs with Clang compilation (confirmed on OS X 10.9), so clang should not be blacklisted anymore.

[mf2k (Frank Schima)]

Thanks. In the future, please Cc the port maintainers (port info --maintainers go).

[bmhatfield@…]

Silly question - but how long until this is merged / released?

[ci42]

Replying to b@…:

Go 1.2 is officially released: ​http://blog.golang.org/go12

Yes, I know. I'm on the golang mailing list(s).

Go 1.2 fixes several bugs with Clang compilation (confirmed on OS X 10.9), so clang should not be blacklisted anymore.

Thanks for the patch but just changing the checksums and removing the clang blacklisting is not enough. The godoc and vet commands have been moved to another repository (see ​http://golang.org/doc/go1.2#go_tools_godoc). Including them in the port requires some extra work.

[ci42]

Replying to bmhatfield@…:

Silly question - but how long until this is merged / released?

Expect the update within the next few days.

[ci42]

Updated to 1.2 in r114986. Currently without the godoc and vet command since the upstream developers refuse to properly tag them (​https://code.google.com/p/go/issues/detail?id=6905&can=1&q=godoc%201.2%20tag&colspec=ID%20Status%20Stars%20Release%20Owner%20Repo%20Summary).

[zquestz (Josh Ellithorpe)]

Seems more like they are using a different way of tracking than the port maintainer wishes... they are in their own branch and could easily be provided. Why hurt all the users that need a complete port for golang because of politics? Not including those other tools makes this port pretty worthless since it is incomplete and most Go editors include godoc and go vet hooks that won't work with this build.

[b@…]

I would prefer to have separate ports for go-vet and go-doc.

[larryv (Lawrence Velázquez)]

Replying to b@…:

I would prefer to have separate ports for go-vet and go-doc.

A separate port or subport that tracks the go.tools subrepository seems like the best solution. Maybe “go-tools”.

[zquestz (Josh Ellithorpe)]

That makes sense, but if you do it as a separate port, would it be locked on a particular SHA, or would it just build the latest within the go 1.2 branch? Seems the issue the maintainer brought up on code.google.com still wouldn't be addressed. The package could change whenever someone commits to that branch.

[larryv (Lawrence Velázquez)]

Replying to quest@…:

That makes sense, but if you do it as a separate port, would it be locked on a particular SHA, or would it just build the latest within the go 1.2 branch? Seems the issue the maintainer brought up on code.google.com still wouldn't be addressed. The package could change whenever someone commits to that branch.

The new port would have to be fixed to a specific changeset. The point would be to divorce Go’s versioning from the tools’ (nonexistent) “versioning”.