Translation How go is using go to compile your own

This is a creation in Article, where the information may have evolved or changed.

The original is in this How go uses go to build itself, the author is Dave Cheney.

———— Translation Divider Line ————

How go is using go to compile your own

This article is based on a speech on the go build process I made for the Sydney Go user group in mid-April 2013.

In the mailing list or IRC channel, people often seek detailed documentation about the Go compiler, runtime, and internal principles. At the moment, the source of the authoritative documentation on Go's internal principles is what I encourage everyone to read. Although this is said, the go build process has stabilized since Go 1.0, so documenting it here might also have its value.

This article provides an overview of the nine Steps of the go compilation process, starting with the source code and ending with a well-tested, installed go. To be concise, all paths are relative to the root path that the source code checks out, $GOROOT/src.

You should learn more about the background by reading from the source code installation go on the golang.org website.

The first step. All.bash

% CD $GOROOT/src%./all.bash

The first step is a little bit out of the All.bash, just calling out another two shell scripts: Make.bash and Run.bash. If you use Windows or Plan 9, the process is basically similar, except that the script ends with. bat or. rc, respectively. In other parts of the article, complete the command with the appropriate extension for the operating system.

The second step. Make.bash

. ./make.bash--no-banner

Make.bash as part of the All.bash content, it also interrupts the build process if it exits. Make.bash has three main tasks, and the first task is to verify that the GO environment is sound. A sanity check has been developed for several years to enable generic identification of the tool that causes the problem, or to indicate where in the environment the build failed.

The third step. Cmd/dist

Gcc-o2-wall-werror-ggdb-o cmd/dist/dist-icmd/dist cmd/dist/*.c

When the sanity check is complete, Make.bash starts compiling the cmd/dist. Cmd/dist replaced the Makefile-based system prior to Go 1 and managed the generation of a small portion of the code in Pkg/runtime. Cmd/dist is a C program that affects the C compiler and header files of the system in order to handle known issues with most platforms. The cmd/dist detects the host's operating system and architecture, $GOHOSTOS and $GOHOSTARCH. This may differ from the values of the $GOOS and $GOARCH that are set for cross-compilation. In fact, the Go build process is building a cross compiler, but in most cases the host and target platform are the same. Next, Make.bash uses the initial arguments to call Cmd/dist to compile the libraries used to support the compiler suite: LIB9, Libbio, and Libmach, and then the compiler itself. These tools are also written in C and compiled by the system's C compiler.

echo "# Building compilers and Go bootstrap tool for Host, $GOHOSTOS/$GOHOSTARCH." Buildall= "-A" if ["$" = "--no-clean"]; Then buildall= "" Fi./cmd/dist/dist Bootstrap $buildall-V # builds Go_bootstrap

Using the compiler suite, Cmd/dist will compile the Go tool: Go_bootstrap. Go_bootstrap is not a complete go tool, for example in order to avoid relying on CGO so pkg/net was abolished. A list of directories containing packages and libraries is compiled, and their dependencies are encoded in the Cmd/dist tool, so it is important to avoid introducing new dependencies in the compilation Cmd/go.

Fourth step. Go_bootstrap

Now that the Go_bootstrap has been built, the final step of Make.bash is to compile the complete Go standard library with Go_bootstrap, including a complete go tool to replace.

echo "# Building packages and commands for $GOOS/$GOARCH." $GOTOOLDIR "/go_bootstrap install-gcflags" $GO _gcflags "\    -ldflags" $GO _ldflags "-V STD

Fifth step. Run.bash

Now that Make.bash has finished, go back to All.bash's execution, which will call Run.bash. Run.bash's task is to compile and test the standard library, runtime, and language test set.

Bash Run.bash--no-rebuild

Because both Make.bash and Run.bash call Go install-a STD, you need to use the –NO-REBUILD flag to avoid repeating the previous steps and –no-rebuild skip the second go install.

# allow All.bash to avoid double-build of Everythingrebuild=trueif ["$" = "--no-rebuild"]; Then Shiftelse Echo ' # Building packages and commands. ' Time go install-a-v STD Echofi

Sixth step. Go test-a STD

Echo ' # Testing packages ' time go test std-short-timeout=$ (expr \* $timeout _scale) Secho

Next Run.bash will run the unit tests written in the testing package in all the packages in the standard library. Because $GOPATH and $GOROOT have the same namespace, you cannot use go test directly ... Otherwise, each package in the $GOPATH is tested individually, creating an alias for the package in the standard library: Std. Some tests are filtered using the-SHORT flag because some tests take a long time and consume a lot of memory.

Seventh step. Runtime and CGO Testing

Run.bash the next sections run the platform's test for CGO support, perform some performance tests, and compile some miscellaneous programs along with the Go release. As time goes by, the list of these miscellaneous programs will grow longer, and they will inevitably be stripped away from the compilation process.

Eighth step. Go Run test

(XCD: /testunset gomaxprocstime Go run run.go) | | Exit $?

The penultimate step of Run.bash calls the compiler and runtime tests in the test directory under $GOROOT. They are tests for the lower-level details of the compiler and the runtime itself. Language specification tests are performed, and the Test/bugs and Test/fixedbugs subdirectories hold independent tests of issues that have been discovered and repaired. The driver test is a small Go program $GOROOT/test/run.go, which executes every. Go file in the test directory. Some. The first line of the go file contains instructions that instruct Run.go to judge the result, for example, the program will fail, or provide a deterministic output queue.

Nineth step. Go Tool API

Echo ' # Checking API compatibility. ' Go tool api-c $GOROOT/api/go1.txt, $GOROOT/api/go1.1.txt \    -next $GOROOT/api/ Next.txt-except $GOROOT/api/except.txt

The last step of Run.bash calls the API tool. The task of the API tool is to ensure the conventions of go 1; export symbols, constants, functions, variables, types, and methods are all compliant with the go 1 API released in 2012. For Go 1 There is a description in Api/go1.txt, while Go 1.1 is in api/go1.1.txt. An additional file, Api/next.txt defines the symbol tables that go 1.1 begins to complement the standard library and runtime. Once go 1.2 is released, this file will become a convention for Go 1.2, and then there will be a new next.txt. There is also a small file: Except.txt, which contains exceptions to the approved Go 1 conventions. You should not easily add content to this file.

Additional Tips and Tricks

You may have discovered that it would be useful for building go,make.bash that do not need to be tested, and Run.bash is also useful when building and testing Go runs. This difference is useful for cross-compiling Go or currently working on a standard library as before.

Update : Thanks to Russ Cox and Andrew Gerrand for feedback and advice.