1. Introduction
2. Installing MacPorts
2.1. Install Xcode
2.2. Install MacPorts
2.3. Upgrade MacPorts
2.4. Uninstall MacPorts
2.5. MacPorts and the Shell
3. Using MacPorts
3.1. The port Command
3.2. Port Variants
3.3. Common Tasks
3.4. Port Binaries
4. Portfile Development
4.1. Portfile Introduction
4.2. Creating a Portfile
4.3. Example Portfiles
4.4. Port Variants
4.5. Patch Files
4.6. Local Portfile Repositories
4.7. Portfile Best Practices
4.8. MacPorts' buildbot
5. Portfile Reference
5.1. Global Keywords
5.2. Global Variables
5.3. Port Phases
5.4. Dependencies
5.5. Variants
5.6. Tcl Extensions & Useful Tcl Commands
5.7. StartupItems
5.8. Livecheck / Distcheck
5.9. PortGroups
5.10. PortGroup Introduction
5.11. PortGroup github
5.12. PortGroup gnustep
5.13. PortGroup golang
5.14. PortGroup haskell
5.15. PortGroup java
5.16. PortGroup perl5
5.17. PortGroup python
5.18. PortGroup ruby
5.19. PortGroup xcode
6. MacPorts Internals
6.1. File Hierarchy
6.2. Configuration Files
6.3. Port Images
6.4. APIs and Libs
6.5. The MacPorts Registry
6.6. Tests
7. MacPorts Project
7.1. Using Trac for Tickets
7.2. Using Git and GitHub
7.3. Contributing to MacPorts
7.4. Port Update Policies
7.5. Updating Documentation
7.6. MacPorts Membership
7.7. The PortMgr Team
8. MacPorts Guide Glossary
Glossary

5.13. PortGroup golang

The golang PortGroup allows for efficient porting of Go-based open source software.

5.13.1. Description

This PortGroup greatly simplifies the porting of software written in Go, especially when the software and its dependencies are hosted on GitHub or Bitbucket. Provided a project author follows common Go packaging practices, a port can be almost fully configured simply by declaring the package identifier.

In particular, Go has strict requirements relating to the arrangement of code on the filesystem (GOPATH). This PortGroup handles the construction of the GOPATH for you.

5.13.2. Setting up the Go package identifier

The main port configuration is triggered by the usage of the go.setup keyword:

PortGroup           golang 1.0
go.setup            domain/author/project version [tag_prefix] [tag_suffix]

By default, the port name will be set to the package name (+project+) and version will be set to the project +version+. The port name can be overridden by using the name keyword.

The tag_prefix and tag_suffix are optional, and are used to specify a prefix/suffix to use when constructing the tag name. If, for example, the project uses tags such as +v1.0.0+, then the tag_prefix should be set to +v+, as in the following example:

go.setup        domain/author/project version v

When the domain is either github.com or +bitbucket.org+, the appropriate PortGroup will be applied and set up automatically. See those PortGroups' documentation for details.

Projects hosted elsewhere can be used, but require additional manual setup.

5.13.3. Setting up dependencies

The PortGroup provides a keyword to facilitate listing dependencies: +go.vendors+. Supply a list of vendor package IDs, their versions (git commit hashes, labeled "lock" as in "lockfile"), and their checksums as follows. The packages and their versions can usually be found in a lockfile (e.g. Gopkg.lock, glide.lock) in the upstream code. All checksum types supported by the <<reference.phases.checksum,checksums>> keyword are supported here as well.

go.vendors      example.com/dep1/foo \
                    lock    abcdef123456... \
                    rmd160  fedcba654321... \
                    sha256  bdface246135... \
                    size    1234 \
                example.com/dep2/bar \
                    lock    abcdef123456... \
                    rmd160  fedcba654321... \
                    sha256  bdface246135... \
                    size    4321

Note that go.vendors cannot be used with dependencies hosted outside of GitHub and Bitbucket. Such dependencies must be handled manually.

After the extraction phase, the vendor packages will be placed alongside the main port code as appropriate in the GOPATH.

5.13.4. Building and destroot

By default this PortGroup runs go build from the +${worksrcpath}+. Assuming this results in a binary with the same name as the project, and that there are no other files to install, the following is sufficient for the destroot phase:

destroot {
    xinstall -m 755 ${worksrcpath}/${name} ${destroot}${prefix}/bin/
}

Please modify as appropriate for each individual port.

5.13.5. golang PortGroup Specific Variables

When the golang PortGroup is declared within a Portfile, the following variables are provided during port install.

go.bin

Default: ${prefix}/bin/go

The Go binary location.

go.package
The package identifier of the port, e.g. +example.com/author/project+.
go.domain, go.author, go.project
The individual parts of +${go.package}+.
gopath

Default: +${workpath}+/gopath

The location where source packages will be arranged after the extract phase.

goarch
Default: 386 or amd64, depending on ${build_arch}
goos
Default: ${os.platform}

5.13.6. golang PortGroup Sugar

Portfiles using PortGroup golang do not need to define the following variables:

name, version, homepage, distname, master_sites, livecheck.*
Default: see github or bitbucket PortGroups (when project hosted on GitHub or Bitbucket)
depends_build
Default: port:go
use_configure
Default: no
platforms

Default: darwin freebsd linux

Go can target these platforms, but individual ports should override this as necessary if only some are actually supported.

build.cmd
Default: ${go.bin} build
build.args
Default: ""
build.target
Default: ""
build.env
Default: GOPATH=+${gopath}+ GOARCH=+${goarch}+ GOOS=+${goos}+ CC=+${configure.cc}+
post-extract
Default: arranges the project and vendor source files appropriately in the GOPATH.