> For the complete documentation index, see [llms.txt](https://thewhitetulip.gitbook.io/bo/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://thewhitetulip.gitbook.io/bo/0.0installation/0.1tools.md). # Tools **HTML**: Brackets, a text editor for the web by Adobe. **Go**: Any IDE of your choice which has a Go language plugin. ## The toolchain The Go programming language comes with a set of tools along with the standard installation. ### gofmt Usage: `gofmt main.go` : Prints the formatted source code of main.go file on the console. `gofmt -w main.go`: Writes the formatted code in the file main.go `gofmt -w Tasks`: Runs gofmt on all the files in the folder Tasks. `go fmt` can be used in place of `gofmt -w`. Most IDEs can be configured to run `gofmt` on save. It is highly recommended to run `gofmt` before committing to version control. ### godoc It extracts documentation comments on all the Go projects present in `$GOPATH/src`, and the standard library present in `$GOROOT`. It has two interfaces: * Web: Usage: `godoc -http=:6060` The documentation of `net/http` is present at `localhost:6060/pkg/net/http`. godoc also allows users to read the Go source code of the packages. Since Go is now implemented in Go itself, we can read the source code of Go language. > Note: Verbose Flag > Depending on how much projects are in your `$GOPATH`, it'll take time for godoc to get up and running, please use `-v` flag. Using the -v flag, we come to know when the server got up. * Commandline: Usage: godoc net/http This will provide the documentation of net/http on the terminal, like the man command. The catch here is that we need to know the exact library name. The packages where comments aren't present show up as blank pages in godoc. #### Documentation The documentation covered by godoc is the documentation about the API, since only the exported functions have documentation comments in godoc. This documentation is different from the logic documentation. ### go test Go has testing support built into the language. For each code file `file.go`, the corresponding test cases should be present in a file named as `file_test.go` in the same folder. The Go compiler ignores all the `*_test.go` files while building the application. ### go build We can build our application using `go build`. It parses all the `.go` files except the `*_test.go` files in the entire folder and all sub folders along with imported libraries if any, and creates a statically linked binary. The binary name is the same as the project folder name, if we want a custom name we should use the -o flag. Example: `go build -o tasks` #### Build time By default, `go build` builds the entire application and the depending libraries, into a static binary and later throws all away. This results in rebuilding everything every single time `go build` is executed. For caching the library builds, use `go install` first and `go build` later. #### Cross compilation Go allows cross compilation. We have to pass the OS name as linux/darwin/windows as GOOS as shown in the below commands. ``` env GOOS=darwin GOARCH=386 go build -o tasks.app env GOOS=windows GOARCH=386 go build -o tasks.exe ``` ### go install Creates a statically linked binary and places it in `$GOPATH/bin`. Also creates a `.a` file of the library and puts it in the $GOPATH/pkg folder. In future builds this library file will be reused until the underlying code is changed. For using tools built with Go like we use unix commands, we need to add `$GOPATH/bin` to the environment variable $PATH. > Note: $PATH > On Linux/Unix the `$PATH` environment variable is a list of directories which are known to have executables. When we call some executable from any terminal, the shell goes through all folders present in `$PATH` one at a time until it finds the executable. In Linux/Unix, this is done using: `export PATH=$PATH:$GOPATH/bin`. This line needs to be added to either `.bashrc` or `.profile`, whichever is being used by the shell. The profile files are present in the home folder. Do a `cd ~` and check for either of the files mentioned above. ### go run go run combines building and running the application in one command. It generates a binary in the temp folder and executes it. The binary file isn't retained after the run. ### go get This is the package manager in Go. It internally clones the version control repository parameter passed to it, can be any local/remote git repository. It then runs `go install` on the library, making the library available in `$GOPATH/pkg`. If the repository doesn't have any buildable files then go get might complain, but that happens after the repository is cloned. ### go clean This command is for cleaning files that are generated by compilers, including the following files: ``` _obj/ // old directory of object, left by Makefiles _test/ // old directory of test, left by Makefiles _testmain.go // old directory of gotest, left by Makefiles test.out // old directory of test, left by Makefiles build.out // old directory of test, left by Makefiles *.[568ao] // object files, left by Makefiles DIR(.exe) // generated by go build DIR.test(.exe) // generated by go test -c MAINFILE(.exe) // generated by go build MAINFILE.go ``` ### Other commands Go provides more commands than those we've just talked about. ``` go fix // upgrade code from an old version before go1 to a new version after go1 go version // get information about your version of Go go env // view environment variables about Go go list // list all installed packages ``` For details about specific commands, `go help `. ### Links -[Previous section](/bo/0.0installation.md) -[Next section](/bo/02.1introductiongo.md)