This is a creation in Article, where the information may have evolved or changed.
Goroot
Golang the installation path.
Gopath
Official explanation, please Google. A very important environment variable that is often used in the go work environment (this design is similar to Java). Specific use: Go commands are often needed, such as go run,go install, go get, etc. Allow multiple paths to be set, as with the Multipath settings for each system environment, Windows uses ";", and Linux (Mac) is separated by ":".
Under Linux (MAC), for convenience, the general configuration is in ~/.bash_profile.
book:~ wukebing$ vi ~/.bash_profile //编辑
book:~ wukebing$ Source ~/.bash_profile//Edit is complete, make immediate effect
Example: My Gopath settings (MAC)
export GOPATH=$HOME/workspace/goexport PATH=$PATH:${GOPATH//://bin:}/binexport GOBIN=
Where, " export PATH=$PATH:${GOPATH//://bin:}/bin " for Linux (MAC), the bin under each Gopath is added to path.
When there are multiple paths, it appears that the first path takes precedence. This does not matter, only the required third-party Package (library) can be properly downloaded and used on the OK.
GOBIN
Go install compile and store the path. Setting multiple paths is not allowed . can be empty. When NULL is followed by the "Convention over Configuration" principle, the executable files are placed in the Bin folder of their respective Gopath directories (provided that the main function file of package main cannot be placed directly under the src of Gopath.
Go Environment view
Use Go env to view the current go environment variables.
Gopath directory Structure
goWorkSpace // (goWorkSpace为GOPATH目录) -- bin // golang编译可执行文件存放路径,可自动生成。 -- pkg // golang编译的.a中间文件存放路径,可自动生成。 -- src // 源码路径。按照golang默认约定,go run,go install等命令的当前工作路径(即在此路径下执行上述命令)。
Go directory structure 1:
project1 // (project1添加到GOPATH目录了) -- bin -- pkg -- src -- models // package -- controllers // package -- main.go // package main[注意,本文所有main.go均指包main的入口函数main所在文件]
project2 // (project2添加到GOPATH目录了) -- bin -- pkg -- src -- models // package -- controllers // package -- main.go // package main
The package main file is directly under the Gopath directory to SRC.
Use go build to compile an executable file named "src" under the src folder. This is the Golang default convention. In general, I do not use this command personally. Because it will generate the executable file under the SRC directory.
I usually use: Go get and go install.
Go get [Main.go path]
parameter [main.go path]: Optional. Relative gopath/src path. The default is. (Src himself). You can specify a subfolder path below SRC.
Go get will do 2 things: 1. Download the required package from the remote. 2. Execute go install. (It can be seen from here that the "Convention is better than the configuration" principle Golang everywhere for brevity)
Go install [Main.go path]
parameter [main.go path]: Optional. Relative gopath/src path. The default is. (that is, the current directory or working directory). You can specify sub-folders below Src.
Go install compiles the executable file named [main.go parent folder name] and puts it under the Gobin path. When Gobin is empty, the default convention is that the resulting executable file is placed in the Gopath/bin folder. The resulting intermediate file (. A) is placed in the project/pkg (without a change, not regenerated. a).
Let's look at this go directory structure 1, and execute go install (and the second stage go install of Go get) Error:
Note: If the environment variable is not changed in an extra way (the company is currently using SH script compilation), it is compiled. Error: Can ' t load package:package.: No buildable Go source files in *
Workaround 1:
Once I was confused by this mistake and thought that all environment variables were fine. Online also not how to see directly clear all answer. After looking at some posts, comprehend by analogy, set the GOBIN environment variable to resolve. (Well, I haven't read the official documents in English yet.) This is the default convention that should be available on official documents. )
There is a drawback to this workaround, and multiple project results can result in multiple Gopath directories. If the directory structure and package are consistent under multiple project, direct compilation can cause compilation problems. Because go takes precedence over the first Gopath directory, it causes a compilation conflict. (Of course, you can also change the GOPATH environment variable every time by hand or step, it feels very troublesome.) It is not recommended that more than one project be set directly to the vast number of gopath. Of course there are solution 2, I think is the standard reasonable solution, is the following GO directory structure 2.
Go directory structure 2:
goWorkSpace // goWorkSpace为GOPATH目录 -- bin -- myApp1 // 编译生成 -- myApp2 // 编译生成 -- myApp3 // 编译生成 -- pkg -- src -- common 1 -- common 2 -- common utils ... -- myApp1 // project1 -- models -- controllers -- others -- main.go -- myApp2 // project2 -- models -- controllers -- others -- main.go -- myApp3 // project3 -- models -- controllers -- others
Multiple project or tool components within a solution are placed side by side in the Gopath src, such as Myapp1,myapp2,myapp3,common Utils.
At this point, Gobin can be empty, compile, can be as follows:
Go install MYAPP1 or go get myApp1
Go install myApp2 or go get myApp2
Go install MYAPP3 or go get myApp3
This is what we all think, the executable program MYAPP1, MYAPP2, MYAPP3 generated under the Goworkspace/bin. Multiple Gopath also have the "add each bin under each Gopath to path".
Tip: What about a package with the same structure under project with the same name?
Some colleagues in the beginner, the habit according to go directory structure 1, to understand the GO directory structure 2 (think just put main to sub-folder, other controllers and other package structure unchanged), there is such doubts. They had this problem, and when the go directory was added to the Gopath, the compilation was problematic because the package name and path are the same (relative to SRC in gopath), go will only find the first matching gopath). Only manually modify Gopath at compile time, or write script compilation. (I feel tired when I look at it, and I add a script to maintain my troubles.) )
The solution is: in addition to common, public tools, components, belong to each project's own things, all along with Main.go moved to the project directory. Go directory structure 2 that's it.
Import the Controllers method under each project: Import Myapp1/controllers,import myapp2/controllers. The import of Go looks for the path to the package, not the package name. You just have to tell go where your bag is, and go will look for the required package from these paths. Just people generally accustomed to the same package name and folder name, easy to misunderstand. Just be aware that only one package name is allowed under a folder, and subfolders are allowed to define different packages.
Import uses a relative path notation: The path is src relative to goroot and Gopath.
You can also set Gobin, and at this point, because the executable file name is different, it is not easy to generate overrides (you need to avoid multiple gopath with the same "MYAPP" project name.) )
Specific or to see a person's preferences and the actual situation. My personal local environment is roughly:
dir -- goWorkSpace1 // 主要是为了区分自己的鼓捣的一些东西和工作上的项目 -- goWorkSpace2 -- bin -- pkg -- src -- myApp1 -- .git -- models -- controllers -- main.go -- myApp2 -- .git -- models -- controllers -- main.go -- myApp3 -- .git -- models -- controllers -- main.go
That is, I have multiple gopath paths in the local Dir/goworkspace1, Dir/goworkspace2.
Note: src under the Gopath directory and Gopath should not be added to source control, but instead each project directory MYAPP1, MYAPP2, and myApp3 independently source-control each time
I generally do not set Gobin, each Gopath under the bin is added to the path.
Excerpt from: http://blog.csdn.net/Alsmile/article/details/48290223