I tried to go build a project, however, it always encounter the following error.
Godeps/_workspace/src/github.com/gocql/gocql/helpers.go:14:2: no buildable Go source files in /home/beego/src/mixpanel/releases/20160304055749/Godeps/_workspace/src/gopkg.in/inf.v0
both gocql and inf.v0 are packages that I installed.
I am confused and I cannot find a solution. Please share some hints on it.
Thanks
1st, make sure you sourced your setup. Next, to build something make sure they are package main. If that doesn't work, go get and try again
Related
Is it possible to do the equivalent of go build ./... in GoLand, so I can see all the errors in the IDE in one go? I have modified some widely used structs and I want to find all the places I need to change.
I have tried a package build at the top of my tree but that "succeeds" very quickly whereas build ./... in the same directory fails as expected.
I also tried a directory build with ./... as a tool argument but that gives an error
can't load package: package -o: cannot find package "-o" in any of:
which I assume is because whatever GoLand is putting around the configuration is not compatible with that argument.
As #nestor-sokil, mentioned above, if you perform the refactoring operations via the IDE tools, Refactor | Refactor This..., then the IDE manages all the changes automatically for you. If you do find places where this doesn't happen or a refactoring tool is missing, you can open an issue on the issue tracker.
That being said, you can follow the instructions below to configure the IDE to run go build ./... for you. The caveat is that it may show problems that are not normally encountered in operations as the command is unaware of build tags, multiple main() function containing files in the same directory, and so on.
You can create an external tool via Settings/Preferences | Tools | External Tools and configure like this:
You can then go to Settings/Preferences | Keymap and search for the name of the tool and assign it a shortcut to execute it more conveniently.
I recently started out with Go programming and I wanted to checkout some open source projects. I cloned one and I wanted to get that imported into IntelliJ Community Edition 2017.1.1 but when I imported the whole project, I get strange errors. Somehow IntelliJ is not able to find the Go binaries.
Here are my settings:
joe-MacBook-Pro:go-ethereum joe$ echo $GOPATH
/Users/joe/Projects/Private/go-projects
joe-MacBook-Pro:go-ethereum joe$
Here is where Go is installed:
joe-MacBook-Pro:go-ethereum joe$ which go
/usr/local/bin/go
joe-MacBook-Pro:go-ethereum joe$
What else should I do? I'm using the Go Lang Plugin for IntelliJ version 0.171.1931
Is there anything else I should do to get this working? Here is the screenshot of the errors that I get!
Maybe this will answer your question:
Please specify a path to Go SDK in Settings/Languages &
Frameworks/Go/Go SDK See
https://github.com/go-lang-plugin-org/go-lang-idea-plugin/wiki/Documentation#setting-up-the-go-sdk
https://intellij-support.jetbrains.com/hc/en-us/community/posts/207004125--No-Go-SDK-defined-for-this-project-getting-this-message-in-WebStorm
I am attempting to compile a go program. The code is a small x11 window manager, found HERE. (The code is 98 lines, too long to post here)
Here is the command I run, on x86-64 Ubuntu:
GOOS=linux GOARCH=386 go build littlewm.go
This command works fine on other files in the same directory. However, when I try to compile this one, I get the following error:
can't load package: package main: no buildable Go source files in /home/ubuntu/workspace/Go
This does not involve the gopath variable, as I have successfully compiled other programs in the same directory. I have a suspicion it involves the code itself or some option I am lacking. As such, this is not really a duplicate of an existing question and is quite possibly unique, since I am not getting the answer I want from other similar questions. Any help is appreciated greatly.
Thanks!
I encountered a similar problem when trying to build my own go program.
I had just added GCO to interface with some native C code in a library.
It built for me for the native platform (the machine I was coding on), but not when I tried to target another platform (using GOOS and GOARCH as you're doing).
Setting CGO_ENABLED to 1 (as mentioned in david's comment) fixed the problem for me:
CGO_ENABLED=1 GOOS=linux GOARCH=386 go build littlewm.go
I was using a makefile to build for multiple platforms using multiple rules, so for me, I put
export CGO_ENABLED = 1
near the top of my makefile so that I didn't need to specify it for each platform.
The way I have my projects structured is similar to the following
/workspace
/src
/package1
/vendor
/src
/somepackage
/anotherpackage
/package1
My GOPATH is set to /workspace;/workspace/vendor
Note this is not using the go 1.5 vendor option.
So far everything has been compiling and working fine within out build / development workflow.
I'm in a situation now where I would like to import a library into the vendor directory workspace/vendor/src/package1 but write some unit tests in the workspace/src/package1 directory..
When the tests run it cannot find methods from the package1 in the vendor dir.
Is there a way to get the vendor package code recognised into the same namespace like this?
Are you asking to essentially "split" the code for a package between two folders in two different gopaths? The go tool cannot do this, as it takes the first folder it finds on any folder in your gopath. If you are actively working on a project, why would it go in the vendor gopath and not in the src one?
It is because of distinctions like this that I generally recommend one gopath for everything. If you want to vendor dependencies I recommend doing that for each individual main package you have.
As captncraig said: The go tool cannot do this.
But you are free to call the go compiler itself on any set of files you want: go tool compile <file.go>...
Of course this would reintroduce some kind of Makefile style build system. It is doable but all the heavy lifting done by go build or go install is lost and will have to live in your Makefiles.
When I try to export a signed copy of my application from the Archives screen, I get the following error.
I used find . -type l ls to find symlinks in my project directory: there are none. I went to the Xcode/Archives folder for this archive and searched for symlinks there, and there are some but none of them are in the DevMateKit.framework mentioned in the error message. I've also tried adding a build step to manually delete the second binary, but it doesn't help.
The code signing is being done automatically by Xcode, and the files are being copied through a standard Copy Files task. There is also one manual piece of code signing, done through a Run Script task, which manually codesigns a different framework to the one in the error message (although I can't see how that would be relevant). My Xcode version is 6.3.1.
Any suggestions?
If you are using DevMateKit v1.1.1 or less, check your 'Link Binary With Libraries' build phase and phase where you are copying frameworks and remove DevMateIssuesReporter.framework from the list if it's present there. If it won't help, just contact DevMate support with this problem or create a new issue with GitHub (https://github.com/DevMate/DevMateKit)
OK, so I believe the reason this happens is as follows. The DevMateKit.framework is pre-codesigned by the developer. But I suspect that their source has symlinks in it, and they have signed it all in such a way that this error occurs, but when packaging the framework for download have removed the symlinks so it appears there is nothing that code be done.
I experimented with signing the code myself, which I think would work, but after some experimentation decided to simply delete the binaries that are directly inside any CrashReporter.framework directory, and leave the ones inside any CrashReporter.framework/Versions/.../ directory. This removes the duplicated binaries and appears to work perfectly.
But I'm not an expert on this process, so it's entirely possible that I was just doing something wrong.