On Tuesday 10 Apr 2012 14:52:10 you wrote:
On 04/05/2012 06:31 PM, Graham Anderson wrote:
Hi Sascha,
I'm going to tweak a couple of locations for the third party go packages. One issue I ran into while developing a package but also having it installed via repos was that the go tool will build using packages/sources it finds in $GOROOT in preference to anything in $GOPATH.
I will move the install location of the third party packages outside of the $GOROOT/pkg location and into $GOROOT/vendor, I'll update the profile env vars to add the vendor dir as the last location in $GOPATH.
$GOPATH would then look something like this: GOPATH=$HOME/go:$GOROOT/vendor
This allows anyone on hacking on a new library version in their GOPATH to build using that in preference to the system installed version without the inconvenience of having to manually pass paths to the compiler.
Sounds like it'S worth discussing with upstream. Let's give it a try.
Sure, I wanted to ask about the Go tool anyway. Some of the behaviour was finalised quite late on and because it's not in the spec I wanted to know if the current behaviour with regards to $GOROOT being prioritised over $GOPATH was going to be guaranteed going forward. I rather suspect we will have to move the install location for third party libs anyway. According to the plans for Go 1.1 in the last comment of this issue: http://code.google.com/p/go/issues/detail?id=2775
package changes ---------------
I added go-mimemagic and removed go-gomagic (not updated since 7 months).
go-socket.io doesn't seem to be developed anymore. I've fixed the current version but it's only life support for anyone who was using that because it only works with socket.io 0.7.x, socket.io is now on 0.9+
I added go-gtk3, gobject instrospection based bindings. needs some patches there's newers methods than older suse versions have and deprecated methods for factory. There's actually a third gtk bindings package that offers generated bindings for both gtk2 and gtk3, I guess I'll try to package that too and people can evaluate which one has the completed features they want.
I added go-falcore http library, some test failures on certain suse versions, will investigate at some point soon since I'm using that library myself. Cool. I wonder whether we should move Go packaging discussions to opensuse-packaging in the future, I know of at least two more guys that would be interested.
Sounds like a plan... Go-OpenGL might need looked at. There was some talk this week on the go-nuts list of difficulties using this since Go 1. I didn't follow the thread too closely but the reporters might not have realised use of Go-OpenGL needs to used with runtime.GOMAXPROCS(1) or the goroutine that invokes the GLContext needs to be locked to the OS thread. We should probably review and assertain the state of development of current DB drivers as well. There are CGO wrappers for C implmentations and native drivers. In general the CGO drivers seem to be the older ones (but not necessarily the ones with most features or the most mature). The native SQL drivers now finnaly seem to be coalescing round the database/sql and database/sql/driver std library API. There are also a bunch of different NoSQL drivers to evaluate. There are competing drivers for MySQL, Postgres, Sqlite3, Oracle, Redis, MongoDB, CouchDB, Kyoto Cabinet and Riak. I doubt I'll be able to evaluate even half of these but I'm pretty sure some of the competing implementations are bit-rotting already. This is one area where we could certainly use an extra pair of hands ;) Cheers the noo, Graham