Go Study Notes (2) – Installation directory, workspace, source files, and standard commands

GOROOT: The path to the Go language installation root directory, which is also the Go language installation path. GOPATH: Path to several workspace directories. It’s a workspace that we define ourselves. Very important before the Go Module mode, it is now basically used to hold items obtained using the Go Get command. GOBIN: Go Installation directory of the generated program. For example, run the Go install command to save the generated Go program to this directory for terminal use.

1. GOROOT installation directory description

The value of GOROOT is the Go installation directory. The installation directory is as follows:

wohu@wohu:/usr/local/go$ ls
api      bin              CONTRIBUTORS  favicon.ico  LICENSE  PATENTS  README.md   src   VERSION
AUTHORS  CONTRIBUTING.md  doc           lib          misc     pkg      robots.txt  test
wohu@wohu:/usr/local/go$
Copy the code

• PKG directory:

wohu@wohu:/usr/local/go$ ls pkg/
include  linux_amd64  linux_amd64_race  tool
Copy the code

You’ll find a folder named Linux_AMd64, which we call the platform dependent directory. The names of these folders are a combination of the names of the corresponding operating system and computing architecture.

With the go install command, the Go program (in this case, the standard library program) is compiled into a platform-specific archive and stored there. In addition, the PKG /tool/ Linux_amd64 folder contains many powerful commands and tools used to create software using Go.

wohu@wohu:/usr/local/go$ ls pkg/linux_amd64
archive    context.a  encoding    fmt.a   html.a    io     math.a  os        reflect.a  sort.a     syscall.a  unicode
bufio.a    crypto     encoding.a  go      image     io.a   mime    os.a      regexp     strconv.a  testing    unicode.a
bytes.a    crypto.a   errors.a    hash    image.a   log    mime.a  path      regexp.a   strings.a  testing.a
compress   database   expvar.a    hash.a  index     log.a  net     path.a    runtime    sync       text
container  debug      flag.a      html    internal  math   net.a   plugin.a  runtime.a  sync.a     time.a
wohu@wohu:/usr/local/go$
Copy the code

2. Description of GOPATH working interval

GOPATH is working on the interval for his own project, which we have set up in note learning (1). You can see all of the environment variables of GO using the Go env.

wohu@wohu:~/gocode$ go env
GOARCH="amd64"
GOBIN="/home/wohu/gocode/bin"
GOCACHE="/home/wohu/.cache/go-build"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/home/wohu/gocode"
GOPROXY=""
GORACE=""
GOROOT="/usr/local/go"
GOTMPDIR=""
GOTOOLDIR="/usr/local/go/pkg/tool/linux_amd64"
GCCGO="gccgo"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD=""
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build076028171=/tmp/go-build -gno-record-gcc-switches"
Copy the code

GOPATH is used as a search path for compiled binaries and import packages (actually your working directory, you can create your own Go source files under SRC and start working). In general, Go source files must be stored in the workspace.

GOPATH contains three directories: bin, PKG, and SRC

wohu@wohu:~/gocode$ echo $GOPATH
/home/wohu/gocode
wohu@wohu:~/gocode$ ls
bin  pkg  src
wohu@wohu:~/gocode$
Copy the code

We need to add the workspace directory path to the environment variable GOPATH. Otherwise, even if you are in the same workspace (in fact, directories that are not added to GOPATH do not need to be workspaces), you cannot call each other through the absolute code package path.

In a real development environment, there can be only one or multiple workspaces, and the directory paths of these workspaces need to be added to GOPATH. As with GOROOT, we should make sure GOPATH is always working.

GOPATH="/home/wohu/gocode"
Copy the code

GOPATH, described in many books and articles on the Go language, is implemented by modifying global environment variables of the system. However, this approach to setting up the global GOPATH can cause the current project to misreference the Go source file in another directory, resulting in the wrong version of the compile output, or the compile to report some unintelligible error message.

For example, save some project code in /home/davy/projecta and set the directory to GOPATH. As development proceeds, it is necessary to obtain a copy of the project’s source code again, which is stored in the /home/davy/projectb directory. If the project needs to be compiled in the projectB directory, the developer forgets to set GOPATH and uses the command line instead. The current GOPATH points to the /home/davy/projecta directory, not the projectB directory the developer expected at compile time. When the compilation is complete, the developer releases the faulty project version to the Internet.

Therefore, it is recommended that you do not set GOPATH globally when compiling the Go source, whether from the command line or using an integrated development environment. Instead, you set GOPATH with your project.

GOPATH means: You can think of GOPATH simply as the Go language’s working directory. The value of GOPATH is the path to a directory or multiple directory paths, each representing a workspace for the Go language.

We need to facilitate these workspaces to place source files for the Go language, archive files (i.e., files with.a extensions) and executable files after install.

Under Linux, archive files are files with an extension of. A, also known as archive files. Friends who have written C programs know that this is a static library file generated after the program is compiled.

In what order does the Go language find dependency packages in multiple workspaces? Answer: GOROOT and then GOPATH.

wohu@ubuntu-dev:~/project/go/src/github.com$ go install github.com/ramya-rao-a/go-outline
can't load package: package github.com/ramya-rao-a/go-outline: cannot find package "github.com/ramya-rao-a/go-outline" in any of:
        /usr/local/go/src/github.com/ramya-rao-a/go-outline (from $GOROOT)
        /home/wohu/project/go/src/github.com/ramya-rao-a/go-outline (from $GOPATH)
Copy the code

Will there be conflicts if there are code packages with the same import path in multiple workspaces? The answer is: no conflict. Because Go looks for code packages sequentially. For workspaces in GOPATH, it looks them up in the order you set them up. So it finds and uses the same path project in the earlier workspace.

2.1 the SRC directory

• srcDirectory: Mainly storesGoSource code file

Organize and save Go source files in code packages that correspond to the SRC subdirectory. For example, if a source file is declared to belong to the code package log, it should be stored in the “SRC /log” directory. Of course, you can also place the Go source files directly in the SRC directory, but such Go source files can only be declared as part of the main package.

Unless used for temporary testing or demonstrations, it is generally recommended to store the Go source files in a specific code package.

GOBIN="/home/wohu/gocode/bin"
Copy the code

wohu@wohu:~/gocode$ ls bin/
dlv  gocode  godef  golint  go-outline  gopkgs  goplay  gorename  goreturns  go-symbols  guru  impl
wohu@wohu:~/gocode$ ls pkg/
linux_amd64  mod
wohu@wohu:~/gocode$ ls src/
github.com  golang.org  hello  hello.go
Copy the code

3.1 Command source file

Declared as part of the main package and containing the source file for the main function that has no argument declarations and no result declarations. This type of source code is an entry point into the program and can be run independently (using the go run command) or converted into an executable by the Go build or Go install command.

All source files in the same package must have the same package name. If the command source file and the library source file are in the same code package, the package will not execute the go build and Go install commands correctly. In other words, these source files cannot be compiled and installed. Therefore, command source files are usually placed in a separate code package. Typically, a program module or software has only one startup entry.

You can have multiple command source files in the same code package and run them separately with the Go run command. However, the go build and go install commands cannot compile and install the code package. Therefore, in general, it is not recommended to put multiple command source files in the same code package.

If only one command source file exists in the code package, run the go build command in the directory where the file resides to generate an executable file with the same name as the directory. If you use the go install command, you can generate the corresponding executable file in the bin directory of the current workspace.

Conclusion: If oneGoThe source file is declared to belong tomainPackage, and the file containsmainFunction, which is the command source file. The command source file belongs to the entry of the program and can be passedGoThe language of thego run The command is executed or passedgo build Command to generate an executable file.

3.3 Test the source file

This is a special library file that runs all the test source files under the current code package by executing the go test command. There are two sufficient conditions to be a test source file:

• The file name must end with _test.go
• The file must contain at least one function with a name starting with Test or Benchmark and one parameter of type * testing.t or testing.b. The types testing.t or testing.b are two structure types.

When you run the go test command in a code package, all the test source files in that code package are found and run.

Note: The text file that stores the Go code needs to be stored in UTF-8 encoding. If a non-UTF-8 encoded character appears in the source file, Go will throw the “illegal UTF-8 sequence” error when running, compiling, or installing.

Code examples:

wohu@wohu:~/GoCode/ SRC $├── ├─ download │ ├── download │ ├── upload │ ├── download │ ├── download │ ├── download │ ├── upload │ ├── download │ ├── download │ ├── upload │Copy the code

Download_demo. go

package download

import "fmt"
// The Download_imge method name starts with a capital letter, which means it can be called externally
func Download_imge(a) {
	fmt.Println("This is download image demo")}Copy the code

Upload_demo. Go

package upload

import "fmt"
// Upload_imge method name starts with a capital letter, indicating that external can be called
func Upload_imge(a) {
	fmt.Println("This is upload image demo")}Copy the code

Main. go code contents:

package main

import (
	"download"
	"upload"
)

func main(a) {
	upload.Upload_imge()
	download.Download_imge()
}
Copy the code

Run the go run, go build, and go install commands respectively, and you can see that the output is normal, the binary file main is generated, and the corresponding binary file is found in the bin directory.

wohu@wohu:~/GoCode/src$ go run main.go This is upload image demo This is download image demo wohu@wohu:~/GoCode/src$ ls download main.go upload wohu@wohu:~/GoCode/src$ go build main.go wohu@wohu:~/GoCode/src$ ls download main main.go upload  wohu@wohu:~/GoCode/src$ ./main This is upload image demo This is download image demo wohu@wohu:~/GoCode/src$ go install  main.go wohu@wohu:~/GoCode/src$ ls .. /bin/ main wohu@wohu:~/GoCode/src$ ls .. /pkg/ wohu@wohu:~/GoCode/src$Copy the code

go vet main.go
Copy the code

4.2 Additional Parameters

When executing the above command, you can customize the execution of the command by attaching some additional tags. Here is a more general tag.

• -n

Causes a command to print only all the commands used in its execution, without actually executing them. If you just want to see or verify the execution of a command and don’t want to change anything, use it.

• -race

Used to detect and report data contention problems in specified Go language programs. This is one of the most important checks when writing concurrent programs in Go.

• -v

This command is used to print code packages involved in command execution. This must include the object code package that we specify, and sometimes those that the code package depends on directly or indirectly. This will let you know which code packages are being processed by the command.

• -work

Print the name of the temporary working directory that is generated and used during command execution and is not deleted after command execution is complete. The files in this directory may be useful to you, as well as give you a side view of the command execution process. If this flag is not added, the temporary working directory will be deleted before the command completes.

• – x:

Causes the command to print all the commands used in its execution and execute them simultaneously.

We can think of these tags as special arguments to a command that can be added between the command name and the actual arguments to the command. They are supported by commands used to compile, install, run, and test Go language code packages or source files. The tool subcommand mentioned above is used to run some special Go language tools. You can see these special tools by executing the go tool command directly. Some of them are low-level support for other Go standard commands, and some of the rules are powerful tools that can stand on their own. Two of these tools deserve special mention.

• pprof

Use to interactively access some performance profiles. The command will analyze the given profile and provide highly readable output information on request. The profiles that the tool can analyze include CPU profiles, memory profiles, and program blocking profiles. These profiles, which contain information about the run of the Go program, can be generated by programs in the library code Runtime and Runtime /pprof.

• trace

It is used to read the Go program trace file and show it in a graphical way. It gives us an inside look at the Go program as it runs. For example, the size and usage of the heap in the current process. For example, how multiple Goruntimes in a program are scheduled and why they are scheduled at any given moment. Go program trace files can be generated by programs in the standard code package “Runtime/Trace” and “NET/HTTP /pprof”.

The two special tools mentioned above are very useful for tuning Go programs. If you want to explore the process of running a program, or want to make the program run faster and more stable, then these two tools are a must. In addition, both tools are directly supported by the Go test command. So you can easily incorporate them into your application testing.