[Translation]go Tools

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

Go tool comes, integrates, fully integrated. I'm not used to Makefile. This article is very good, long ago want to translate, but recently burned ... Whatever it is, it's done.

The original text to turn over the wall, visit please caution: The Go Tool

—————-Translation Divider Line —————-

I decided to write something about it after the latest weekly release of the Go Command was introduced online. I have to admit that when I first heard about the unified Go tool, I was full of suspicion and very frightened. I fear it will be as confusing as most other language-specific package managers. Personally, most of these package managers are reinventing the wheel and conflict with the operating system's package manager, making it more difficult for system administrators to live. In addition, I do like makefile, they are simple and direct, and work very well. Fortunately, the new Go tool has dispelled my fears!

Refuse to repeat ...

Recently there is a lot of information about the new Go tool on the Go Nuts mailing list. The official Go document also contains a few passages on how to write go code using the Go tool.

Anyway, I think there are still some gaps in these documents, so this becomes a quick guide to writing about new go tools and a good reason to demonstrate some techniques.

Conventions for configuration

This is the biggest source of my fear, mostly because of my experience with Ruby on Rails. All developers familiar with Rails will agree that whenever you try to make minor improvements, a little bit of tricks, something that doesn't follow the rules, it's ...

But let's talk about best practices. First, each Go tool does only one thing and does the job well. For example, we have:

• go build– Compile the package,
• go get– Resolve and install dependencies,
• go test– Perform test cases and performance tests,
• go install– Installation package,
• go doc– Generate Documents,
• go fmt– Format code,
• go run– Build and Execute applications,
• go tool– Call the extension tool,
• Wait a minute......

The Go package does not have any build configurations . No makefile, no dependency description and so on. So how does it work? All are taken from the code . In order for this magic to take effect, there is one thing to do first. Need to specify where go those 7788 exist. The environment variable gopath defines the path to the Go code tree. For example, the following is in ~/.BASHRC:

Gopath= "/home/nu7/gocode"

...... Tell the Go tool that your go code tree is stored in the specified directory. But you might want to know what the Go code tree really is ? Simply put, it's where all the go resources, packages, and commands are stored . For example:

$ ls/home/nu7/gocode/bin   pkg   src

All the code will be placed in the SRC directory. All of the code I'm talking about means including your apps, packages, and dependencies. The PKG directory contains the compiled and installed packages, while the bin holds the commands.

The Gopath variable works in a way similar to path, so you can set up a number of go paths. It's important to remember that the first one is the primary path, so the content that is installed with go install will be stored here.

Resolve Dependencies

There is no configuration file to describe dependencies ... So the smart Go tool is how to determine what to install, and where to download it! Do you think there is a warehouse somewhere? No, that's not true! Go brings something called Importpath, to see:

Import "Github.com/nu7hatch/gouuid"

The import path is two-in-one. It is the code warehouse URL and the local path to which the package will be installed. The go get tool only needs to look at the import path to know where to get dependencies, and go build knows where to import them locally.

In order to install dependencies in the system , you must use the Go Get tool:

$ go Get package-name

Wait, wait...... What's the package-name here? This is the name of the dependent package that you want to install. Assuming that there is a package called Foo in the Go code, calling go get foo will install all of its dependencies. You can also run the tool directly in the package:

$ cd ~/gocode/src/foo$ go get.

All other go tools work in a similar way and can be called directly in a package, or specify an import path. It can also be used on a set of nested packages ... (three points) a pass-through command. If the Foo package contains some nested packages, in order to install all the required dependencies at once, simply execute:

$ go get./...  

If the specified dependency is already installed in the Go Code tree, it will not be updated unless explicitly specified. When performing a dependent installation of go get , increase the- u identity to update:

$ go get-u package-name

It's simple, isn't it?

Dependence of Hell!

The Go tool has a convention that I particularly like, but I'm afraid at the same time ... go tools resolve dependencies by checking out the HEAD version of the codebase . This forces the package to remain backwards compatible, and ...

The Green Line policy is what I have been insisting on in my work. The default branch is always checked out first, so it should be kept clean , or at least it should work ! Once officially released, or already mature, it should also have the ability to be backwards compatible --it's not always possible to overturn or modify the API on patches or small versions.

But we all know what's going on in practice. Many figures treat backwards compatibility as a piece of crap, or a default branch as a playground, and so on. I have some suggestions for those people, and all the developers who want to live peacefully with the new Go tool ...

The rules that should be followed in a damned Programmer's career:

• Keep the damn line clean!
• Develop a damn new feature on a damn stand-alone branch!
• Once you have published the Code, and some people use it, don't change the api!.
• If you want or have to modify the API, modify the TMD major version number and do the damn development on a new code base separate from the original code base!
• If necessary, it is very necessary to use some special tags, do branch or submit as a dependency, you have to TMD with your own fork out of the code base for TMD required to submit!
• Oh, and keep it simple , son of a.

Don't let me read you a book of Ezekiel (a prophet in the Hebrew Bible) to remind you of this ...

Build and install

OK, let's go back to the Go command. The go build command is used to compile the package. It compiles only the specified packages without installing them. It is important that it requires that the package be checked out in the local code tree . To install a remote package, you should use go get instead:

$ go Get github.com/nu7hatch/gouuid

Install the local package of course use the Go Install tool. (if necessary) it builds the package first and installs it in the $GOPATH/pkg or/and $GOPATH/bin.

The Go tool can also ignore files when it is built, without explicitly specifying additional parameters or special configurations. The only thing to do for a file to ignore is to have an underscore before its name:

$ ls_bar.go   foo.go$ go build.

In the example above, the build-time _bar.go will be ignored.

Well, that's it ... I think there's nothing more to say about this, let's move on to the next section.

Using CGO's C extension

Go provides good support for building C extensions with the CGO command. In fact, compiling most C-supported applications is not even necessary to understand the Cgo,go build tool enough.

To tell you the truth, there's really nothing to say about CGO, and the documentation and the go user wiki article already covers most of the content.

The first thing to say is what I really don't like, which is the practice of writing C code in comments in the official case. You need to know that these examples are primarily intended to reduce the size of the code and allow each example to be demonstrated in the same file. In practical applications, C code should not be placed in the comments section ! The Go build tool intelligently handles. h and. c files in the package.

Need some examples? Consider a simple echo command that prints all the parameters to the screen, but uses the printf function from stdio.h. As stated on the wiki,go does not allow you to invoke the C function of the variable-length parameter , so you need to write a simple package for the printf function. The code looks something like this (and can also be browsed on GitHub):

Echo.h:

#ifndef _echo_h_#define _echo_h_#include <stdio.h>void ECHO (char*); #endif/* _echo_h_ */

ECHO.C:

#include "echo.h" void Echo (char* s) {    printf ("%s\n", s);}

Echo.go:

Package main/* #include <stdlib.h> #include "echo.h" */import "C" Import (        "flag"        "unsafe"        "strings") Func Main () {        flag. Parse ()        cs: = C.cstring (strings. Join (flag. Args (), ""))        C.echo (CS)        C.free (unsafe. Pointer (CS))}

You can now seamlessly compile everything with the go build tool. It can identify all C files in the package. Simply put, this will work!

Building a specific platform

Another cool but interesting place to go is to work on a specific platform file. It can be identified by name (must be like File_goos_goarch.go or file_goarch.go):

Foo_darwin_amd64.gofoo_386.gofoo.go

This function also applies to C files:

Foo_amd64.cfoo_386.cfoo.hfoo.go

As you can see in the documentation, you may never be able to use this feature, but I'd like to show you how flexible the Go tool is on such a simple basis.

OK, but some of you may ask, if you want to do something tricky, you need special compilation parameters or some configuration, such as ...

Savior Makefile

Yes, don't be afraid to use makefile! This is the easiest way to do additional configuration, some pre-request, and so on. Makefile is not only useful for C extensions, but also for applications with multiple packages (for example, using a top-level makefile in Webrocket to make tasks easier).

More clear examples ... Imagine an application that contains kernel packages and command-line tools based on this. You can apply the echo example, but more modular:

echo/  pkg/    echo/      echo.c      echo.h      echo.go  cmd/    echo/      echo.go

Hopefully, the Pkg/echo package provides a reusable C printf function package, and its code looks the same as in the previous example. The Cmd/echo command is an executable file that uses a core package to print to the screen. The Cmd/echo command is this:

Package Mainimport (        "Github.com/nu7hatch/cgoecho2/pkg/echo"        "flag") Func main () {        flag. Parse ()        echo. Echo (flag. Args () ...)}

Note : For those who do not know slice ... means to map a slice to a variable-length parameter, just like the *args in Ruby.

Back to the topic, in order to make the work of the package more simple, need some Makefile. It looks like this:

All:echo-pkg echo-cmdecho-pkg:    go build./pkg/echoecho-cmd:    go build./cmd/echo

It is now possible to quickly compile packages and commands by calling make to two parts, and it is important to use the go command to install remotely :

$ go Get Github.com/nu7hatch/cgoecho2/cmd/echo

Of course, this is a very simple example where you can use a wildcard to build quickly, without having to make a fuss about it:

$ go build./...

But in the face of larger applications, including many packages and/or commands will be benevolent. There are a variety of reasons to use makefile, shell scripts, or any build tool you like.

Summarize

I have to make it clear that I'm a TMD super-fan of the new Go tool! I had a lot of trouble with my first use, but mostly because of my bad habits from other package management tools. Well, I recently asked a lot of stupid questions on go-nuts IRC, and the answer I wanted was so obvious and simple ...

Now review all the tools used, such as Easy_install, RubyGems or bundler, and I have only one impression of them ... Oh, I still don't want to say it, lest many people hate me:). Instead, I can show you how I look at the new Go tool ...

I am glad to see that Go is developing in the right direction. Let's get here today, good luck, Gopher!