Godeps, vendor: switch to Go 1.6 vendored dependencies #2512
Conversation
Updated: Tue Jul 12 09:39:21 UTC 2016 |
karalabe
force-pushed
the
go-vendored-deps
branch
4 times, most recently
from
ffac425 to
7711013
Compare
| @@ -152,7 +152,7 @@ func (n *Node) Start() error { | |||
| } | |||
| // Otherwise copy and specialize the P2P configuration | |||
| running := new(p2p.Server) | |||
| *running = *n.serverConfig | |||
| reflect.ValueOf(running).Elem().Set(reflect.ValueOf(n.serverConfig).Elem()) // Fancy *running = *n.serverConfig to prevent mutex copy | |||
There was a problem hiding this comment.
There was a problem hiding this comment.
I understand the intention to fix the go vet issue but this is not a good fix for it.
We need to find another way. I can remove the mutex as a quick workaround.
That's weird. Why do we vendor 'junk' that is not used? If godep leaves unused dependencies in the I don't mind that |
|
Well, for starters, the windows pipe package isn't build constrained to windows only, so every other platform will fail to build |
|
That sounds like an issue we can fix though. |
|
I understand your point, but do tell me how you think we can solve it? I don't think doing manual patches to upstream dependencies is such a good idea. |
|
Another example that breaks is @Gustav-Simonsson 's opencl dependency, since even though ethash has a build tag/constrain to only use it if requested, when doing |
|
This affects more than just the golang version... Build server steps, Homebrew formula and deb packaging scripts will all need to be changed to support this, and it also means we'll have to yet again split the build procedures for master and develop like the good ol' PoC days. So this will need a little more planning besides just getting the builds to pass again. |
|
What about Windows? I think I've got the others ready at least for the buildslaves with 1.6 and the build steps with |
|
It's true that we can't build with I'd say the easiest way would be to add a .bat script to go-ethereum that does the build on both master and develop. Compared to the make build it would still require setting up |
|
@karalabe So besides ARM and Windows, all that should be left is the deb packaging (the @tgerring Could you update golang to 1.6 on the Windows buildslave? |
|
@caktux I've souped up our makefile in this PR #2520 to handle the cross build issue of Go, but I hit a gcc issue in your arm images ( |
|
Fixed, wasn't passing the env, but then we obviously can't test cross-compiled binaries either so just removed the test step as it was before. Once #2520 is merged it might be good to rebase this one. |
|
@caktux Windows scripts are present on both master and develop now. Any news on the PPA? |
|
👍 |
|
We'll redo this change in the new build/ci.go script when Go 1.7 is out and available for most distros. |
This PR finally moves all of our dependencies to the
vendorfolder. This should enable our repository to be go gettable, and most importantly, reusable as a library in other Go projects without needing to jump though insane dependency management hoops. Yay! 🎉Note: with the introduction of the vendor folder we can no longer do
go install ./..., as that would install everything fromvendortoo, most of which are junk which we don't vendor nor use. This is a known wontfix issue. I've updated theMakefileaccordingly to skip the vendor folder when building and only use it for the dependencies, not as main codebase.