golang doc 代码
文件路径：/src/go/build/doc.go
/ Copyright 2011 The Go Authors. All rights reserved.
/ Use of this source code is governed by a BSD-style
/ license that can be found in the LICENSE file.
/ Package build gathers information about Go packages.
/
/ # Go Path
/
/ The Go path is a list of directory trees containing Go source code.
/ It is consulted to resolve imports that cannot be found in the standard
/ Go tree. The default path is the value of the GOPATH environment
/ variable, interpreted as a path list appropriate to the operating system
/ (on Unix, the variable is a colon-separated string;
/ on Windows, a semicolon-separated string;
/ on Plan 9, a list).
/
/ Each directory listed in the Go path must have a prescribed structure:
/
/ The src/ directory holds source code. The path below 'src' determines
/ the import path or executable name.
/
/ The pkg/ directory holds installed package objects.
/ As in the Go tree, each target operating system and
/ architecture pair has its own subdirectory of pkg
/ (pkg/GOOS_GOARCH).
/
/ If DIR is a directory listed in the Go path, a package with
/ source in DIR/src/foo/bar can be imported as "foo/bar" and
/ has its compiled form installed to "DIR/pkg/GOOS_GOARCH/foo/bar.a"
/ (or, for gccgo, "DIR/pkg/gccgo/foo/libbar.a").
/
/ The bin/ directory holds compiled commands.
/ Each command is named for its source directory, but only
/ using the final element, not the entire path. That is, the
/ command with source in DIR/src/foo/quux is installed into
/ DIR/bin/quux, not DIR/bin/foo/quux. The foo/ is stripped
/ so that you can add DIR/bin to your PATH to get at the
/ installed commands.
/
/ Here's an example directory layout:
/
/ GOPATH=/home/user/gocode
/
/ /home/user/gocode/
/ src/
/ foo/
/ bar/ (go code in package bar)
/ x.go
/ quux/ (go code in package main)
/ y.go
/ bin/
/ quux (installed command)
/ pkg/
/ linux_amd64/
/ foo/
/ bar.a (installed package object)
/
/ # Build Constraints
/
/ A build constraint, also known as a build tag, is a condition under which a
/ file should be included in the package. Build constraints are given by a
/ line comment that begins
/
/ /go:build
/
/ Build constraints may also be part of a file's name
/ (for example, source_windows.go will only be included if the target
/ operating system is windows).
/
/ See 'go help buildconstraint'
/ (https://golang.org/cmd/go/#hdr-Build_constraints) for details.
/
/ # Binary-Only Packages
/
/ In Go 1.12 and earlier, it was possible to distribute packages in binary
/ form without including the source code used for compiling the package.
/ The package was distributed with a source file not excluded by build
/ constraints and containing a "/go:binary-only-package" comment. Like a
/ build constraint, this comment appeared at the top of a file, preceded
/ only by blank lines and other line comments and with a blank line
/ following the comment, to separate it from the package documentation.
/ Unlike build constraints, this comment is only recognized in non-test
/ Go source files.
/
/ The minimal source code for a binary-only package was therefore:
/
/ /go:binary-only-package
/
/ package mypkg
/
/ The source code could include additional Go code. That code was never
/ compiled but would be processed by tools like godoc and might be useful
/ as end-user documentation.
/
/ "go build" and other commands no longer support binary-only-packages.
/ Import and ImportDir will still set the BinaryOnly flag in packages
/ containing these comments for use in tools and error messages.
package build