I have a project structure that looks like so:
I was planning on just using a shell script (build.sh) to set GOPATH and build the project.
I am not sure how to build a Golang project properly, my short term goal is to just to build the packages in the src directory and put the binaries into the bin directory.
I am not sure what go build command can do that, I have tried a few things.
So first my question is - is this a reasonable project structure and second, how can I compile my src directory to bin?
What I have gives me the following error:
can't load package: package .: no buildable Go source files in /home/oleg/WebstormProjects/oresoftware/stack-server
So I believe I need to tell Go to look in the src directory, because Go is only looking for .go files in the project root, but I am not sure how to do that.
If it matters, the main.go file has a package name of "main".
GOPATH=$PROJECT_DIR && cd $PROJECT_DIR && go install main
Also move your main.go file into src/main/main.go.
This will produce a bin/main executable.
If you have multiple executables you wanna build, you have to put each main.go file into a separate folder/package. The name of the generated executable is taken from the directory name the file is inside. The package name of the main.go files must always be main if it should create a binary.
To compile multiple executables you have to use:
GOPATH=$PROJECT_DIR && cd $PROJECT_DIR && go install ...
The ... matches all folders/packages.
Related
I have a local Go project which requires another data file to live with it, as in
my_project/
go.mod
my_tool.go
data.txt
go.mod:
module my_project/my_tool
go 1.19
Until today, I had the path to my_project directory inserted in the $PATH environment variable so I could build the executable file with go build and run it from anywhere.
Then I wanted to try and run go install (with no arguments, as shown in this tutorial) from my_project directory. So I did and noticed that the command does two things:
go install builds the executable file just like go build does;
go install moves the executable file —the file itself, not its symlink— to the $GOPATH/bin directory.
But the go install command does not put any other project file to $GOPATH/pkg/mod — which is a no-go for my tool which requires its buddy data.txt file to be located in the same filepath.Dir(os.Executable()) directory as the executable file.
Neither does the go install my_project/my_tool command. Hence the question:
Is it possible to install a local Go package in the $GOPATH directory in such a way that it can find the location of the other files belonging to the project without me having to add the project directory to $PATH?
I just started writing Go today (so 0 experience), and wonder if Go supports any form of "building all source files" like what mvn install does.
My project structure is
src
`-github.com
`-myproject
|- package1
| `- main.go
`- package2
|- lib1_used_by_main.go
`- lib2_used_by_main.go
When I do
cd src/github.com/myproject
go build
this fails with no buildable Go source files in src/github.com/myproject, which is kind of right, because all source files are in subpackages.
Is there a command to build all subpackages, without listing each of them explicitly?
After you cd to the base directory, use go build ./... Note that there are 3 periods as it is an ellipsis. This will recursively build all subdirectories. Of course you can always do go build path/to/my/base/... from wherever without needing to cd to the directory.
This is very useful for those who use an IDE that relies on the go/pkg directory, such as SublimeText3 with GoSublime. Making changes to a dependency package won't update the autocompletes until you build the package, which places it in the go/pkg directory.
My own projects are broken into a multiple package structure, so I frequently have to go build ./... to update my autocompletion.
Everything I read about the vendor directory gives me the understanding that if I have a directory:
$GOPATH/src/vendor
And put my dependencies in there (I am using godeps), when doing go run, go should check in that directory first.
If I run my code in a Docker image I have, this works fine. However now that I try to run the same code on my Windows machine, go simply ignores the vendor/ directory, and fails to find the dependencies.
What am I doing wrong?
main.go:7:2: cannot find package "gopkg.in/alecthomas/kingpin.v2" in any of:
C:\Go\src\gopkg.in\alecthomas\kingpin.v2 (from $GOROOT)
C:\Users\js\dev\my_project\rest\src\gopkg.in\alecthomas\kingpin.v2 (from $GOPATH)
C:\Users\js\dev\go\src\gopkg.in\alecthomas\kingpin.v2
Is the output when I try to do:
go run main.go
A directory vendor/ exists in this directory.
go version go1.7 windows/amd64
The exact commands I run (in windows cmd.exe)
> cd C:\Users\js\dev\my_project\rest\
> set GOPATH=C:\Users\js\dev\my_project\rest\;c:\Users\js\dev\go
> cd src
> dir
...
2016-09-01 23:20 2 923 main.go
...
2016-09-03 01:27 <DIR> vendor
> go run main.go
The reason this did not work is because you are not supposed to put any code directly into the $GOPATH/src/ directory.
The solution is to put your project into a sub-directory like so:
$GOPATH/src/app/*.go
Seems your GOPATH is incorrect?
The GOPATH should specify the location of your workspace i.e. directory containing src, pkg and bin directories at its root.
Try doing
set GOPATH=C:\Users\js\dev\my_project\rest\;c:\Users\js\dev\go
More details at: https://golang.org/doc/code.html
The first thing to understand is that godep save is simply copying dependencies from your $GOPATH to a vendor directory inside your project.
You will have to go get your dependencies first. After you have them in $GOPATH, you can do a godep save to copy the current version to your project, and be assured that even if the version in $GOPATH changes, you will have a fixed version in your project until you explicitly change it via godep.
So, if I have a $GOPATH of /home/me/go_workspace, and a project called $GOPATH/src/github.com/project_x with a dependency of github.com/you/xyz, then I would do go get github.com/you/xyz, and godep save from within my project directory. This would create a vendor folder with the dependency at its current commit inside.
Right now I'll just run go build __.go, but I'm wondering if it's possible to have that file built in a subdirectory (e.g. a /bin folder). It would just make gitignoring the binary files a lot cleaner, and right now I'm not really sure what else is a good approach as I'm also struggling to create a working gitignore exception rule that isn't just "Ignore all files, except .go files".
My current solution is naming the binary files every time I build them (e.g. go build -o hello.bin hello.go), but this seems laborious.
you can use the -o flag.
cd to the directory where you have the main.go file.
use this command - go build -o DirectoryPath
Where DirectoryPath is the location where you want to create the binary file to.
Instead of using go build *.go, you can do following:
Setup Go workspace, using this official go resource: How to write go code
Define GOBIN and GOPATH environment variable.GOBIN environment variable will point to the directory where you want to store your executables.GOPATH environment variable will point to the directory, where you've setup go workspace.
Now, instead of doing go build *.go, you can use go install {YourCodePath}, where {YourCodePath}, is relative path of your code in go workspace. And if the build is successful, you can find your executable in directory, pointed by GOBIN.
I have a small program that consists of three files, all belonging to the same package (main). But when I do go build main.go the build doesn't succeed. When it was just one file (main.go), everything worked fine.
Now that I took some effort to separate the code, it looks like the compiler is unable to find the stuff that was taken out of main.go and put into these two other files (that reside in the same directory as the main.go). Which results in undefined 'type' errors.
How to compile this program that consists of multiple files?
New Way (Recommended):
Please take a look at this answer.
Old Way:
Supposing you're writing a program called myprog :
Put all your files in a directory like this
myproject/go/src/myprog/xxx.go
Then add myproject/go to GOPATH
And run
go install myprog
This way you'll be able to add other packages and programs in myproject/go/src if you want.
Reference : http://golang.org/doc/code.html
(this doc is always missed by newcomers, and often ill-understood at first. It should receive the greatest attention of the Go team IMO)
When you separate code from main.go into for example more.go, you simply pass that file to go build/go run/go install as well.
So if you previously ran
go build main.go
you now simply
go build main.go more.go
As further information:
go build --help
states:
If the arguments are a list of .go files,
build treats them as a list of source files specifying a single package.
Notice that go build and go install differ from go run in that the first two state to expect package names as arguments, while the latter expects go files. However, the first two will also accept go files as go install does.
If you are wondering: build will just build the packages/files, install will produce object and binary files in your GOPATH, and run will compile and run your program.
Since Go 1.11+, GOPATH is no longer recommended, the new way is using Go Modules.
Say you're writing a program called simple:
Create a directory:
mkdir simple
cd simple
Create a new module:
go mod init github.com/username/simple
# Here, the module name is: github.com/username/simple.
# You're free to choose any module name.
# It doesn't matter as long as it's unique.
# It's better to be a URL: so it can be go-gettable.
Put all your files in that directory.
Finally, run:
go run .
Alternatively, you can create an executable program by building it:
go build .
# then:
./simple # if you're on xnix
# or, just:
simple # if you're on Windows
For more information, you may read this.
Go has included support for versioned modules as proposed here since 1.11. The initial prototype vgo was announced in February 2018. In July 2018, versioned modules landed in the main Go repository.
In Go 1.14, module support is considered ready for production use, and all users are encouraged to migrate to modules from other dependency management systems.
You could also just run
go build
in your project folder myproject/go/src/myprog
Then you can just type
./myprog
to run your app
It depends on your project structure. But most straightforward is:
go build -o ./myproject ./...
then run ./myproject.
Suppose your project structure looks like this
- hello
|- main.go
then you just go to the project directory and run
go build -o ./myproject
then run ./myproject on shell.
or
# most easiest; builds and run simultaneously
go run main.go
suppose your main file is nested into a sub-directory like a cmd
- hello
|- cmd
|- main.go
then you will run
go run cmd/main.go
You can use
go build *.go
go run *.go
both will work also you may use
go build .
go run .
Yup! That's very straight forward and that's where the package strategy comes into play. there are three ways to my knowledge.
folder structure:
GOPATH/src/
github.com/
abc/
myproject/
adapter/
main.go
pkg1
pkg2
warning: adapter can contain package main only and sun directories
navigate to "adapter" folder. Run:
go build main.go
navigate to "adapter" folder. Run:
go build main.go
navigate to GOPATH/src
recognize relative path to package main, here "myproject/adapter". Run:
go build myproject/adapter
exe file will be created at the directory you are currently at.