[[Wikipedia:Go (programming language)|Go]] is well supported on Arch Linux.

[[Wikipedia:Go (programming language)|Go]] is well supported on Arch Linux.

−

The {{Pkg|go}} package contains the '''go''' tool (for running {{Ic|go fix}}, {{Ic|go build}} etc) and there is also the {{AUR|gccgo}} package which provides {{Ic|gccgo}} and {{AUR|go-hg}} in [[AUR]].

+

The {{Pkg|go}} package contains the '''go''' tool (for running {{Ic|go fix}}, {{Ic|go build}} etc). There is also the {{AUR|go-hg}} package in [[AUR]] and {{Pkg|gcc-go}} which provides {{Ic|gccgo}}.

= General guidelines =

= General guidelines =

Line 13:

Line 13:

* For libraries written in Go, use {{Ic|go-''modulename''}}, in lowercase.

* For libraries written in Go, use {{Ic|go-''modulename''}}, in lowercase.

* If the name already starts with {{Ic|go-}}, don't call the package {{Ic|go-''go-modulename''}}, but just {{Ic|go-''modulename''}}.

* If the name already starts with {{Ic|go-}}, don't call the package {{Ic|go-''go-modulename''}}, but just {{Ic|go-''modulename''}}.

−

* For PKGBUILDS that uses the "go" tool to download the package, only add "-git" to the package name if the ''_gitroot'' and ''_gitname'' variables are used.

+

* For PKGBUILDS that uses the "go" tool to download the package, only add "-git" to the package name if it's not built from a tarball or a from a tagged release (but from trunk/HEAD).

−

** Similarly for mercurial packages, only add "-hg" to the package name if the ''_hgroot'' and ''_hgname'' variables are used.

+

** Similarly for mercurial packages, only add "-hg" to the package name if it's not a release-revision.

** Extend this pattern for other version control systems.

** Extend this pattern for other version control systems.

** The go tool has its own logic for which branch or tag it should use. See {{Ic|go get --help}}.

** The go tool has its own logic for which branch or tag it should use. See {{Ic|go get --help}}.

Line 22:

Line 22:

== Packaging ==

== Packaging ==

−

* Go applications are either just library files, just executables or both. Choose an appropriate way of packaging them. There are several examples below.

+

* Go projects are either just library files, just executables or both. Choose the appropriate way of packaging them. There are several examples below.

−

* Some Go applications or libraries have not been updated to Go 1 yet.

+

* Some Go applications or libraries have not been updated to the latest version of Go yet.

** Running {{Ic|go build -fix}} may often work, but it may have to be fixed by the developer. Report an issue upstream if this is the case.

** Running {{Ic|go build -fix}} may often work, but it may have to be fixed by the developer. Report an issue upstream if this is the case.

* Several Go projects doesn't have a version number or a license file.

* Several Go projects doesn't have a version number or a license file.

Line 29:

Line 29:

** Use version "0.1", "1" or the git-revision (or equivivalent for other version control systems) if the version number is missing.

** Use version "0.1", "1" or the git-revision (or equivivalent for other version control systems) if the version number is missing.

** Alternatively, use the current date as the version number, in this form {{Ic|YYYYMMDD}}.

** Alternatively, use the current date as the version number, in this form {{Ic|YYYYMMDD}}.

+

* Since Go applications are usually statically compiled, it's hard to envision reasons for packaging Go libraries instead of just Go applications.

= Sample PKGBUILDs =

= Sample PKGBUILDs =

Line 49:

Line 50:

build() {

build() {

−

cd "$srcdir/$pkgname-$pkgver"

+

cd "$pkgname-$pkgver"

−

source /etc/profile.d/go.sh

go build

go build

}

}

package() {

package() {

−

cd "$srcdir/$pkgname-$pkgver"

+

cd "$pkgname-$pkgver"

install -Dm755 "$pkgname-$pkgver" "$pkgdir/usr/bin/$pkgname"

install -Dm755 "$pkgname-$pkgver" "$pkgdir/usr/bin/$pkgname"

Line 68:

Line 68:

* {{AUR|dcpu16}}

* {{AUR|dcpu16}}

−

== Sample PKGBUILD for when only a single go file is available ==

+

== Sample PKGBUILD for when only a single source file is available ==

{{bc|<nowiki># Maintainer: NAME <EMAIL>

{{bc|<nowiki># Maintainer: NAME <EMAIL>

Line 85:

Line 85:

build() {

build() {

−

cd "$srcdir"

−

−

source /etc/profile.d/go.sh

go build -o "$pkgname"

go build -o "$pkgname"

}

}

package() {

package() {

−

cd "$srcdir"

−

install -Dm755 "$pkgname" "$pkgdir/usr/bin/$pkgname"

install -Dm755 "$pkgname" "$pkgdir/usr/bin/$pkgname"

}

}

Line 102:

Line 97:

* {{AUR|gorun}}

* {{AUR|gorun}}

−

== Sample PKGBUILDs for Go libraries ==

+

== Sample PKGBUILDs for Go libraries that also includes executables ==

−

{{Note| Not all libraries are upgraded to work with Go1 yet! If in doubt, try installing with {{Ic|go get}} first, before packaging.}}

+

=== Using ''go get'' ===

−

=== Using ''go get'' '''(recommended)''' ===

+

This is the recommended way, instead of the method below.

−

+

−

Here's a way that relies on {{Ic|go get}}.

+

−

+

−

You probably won't need to modify the build() or package() functions at all, only the variables at the top (pkgname etc).

+

−

+

−

If this doesn't work, test with {{Ic|go get}} first. Change ''mercurial'' to ''git'', if that's what your package uses.

+

−

+

−

{{Note| Remove {{Ic|/...}} if the PKGBUILD fails!}}

+

−

+

−

{{bc|<nowiki># Maintainer: NAME <EMAIL>

+

−

+

−

pkgname=go-net

+

−

pkgver=20120515

+

−

pkgrel=1

+

−

pkgdesc="Extra network libraries for Go (dict, spdy, websocket)"

+

−

arch=('x86_64' 'i686')

+

−

url="http://code.google.com/p/go"

+

−

license=('BSD')

+

−

depends=('go')

+

−

makedepends=('mercurial')

+

−

options=('!strip' '!emptydirs')

+

−

_gourl=code.google.com/p/go.net

+

−

+

−

build() {

+

−

cd "$srcdir"

+

−

GOPATH="$srcdir" go get -fix -v -x ${_gourl}/...

+

−

}

+

−

+

−

check() {

+

−

source /etc/profile.d/go.sh

+

−

GOPATH="$GOPATH:$srcdir" go test -v -x ${_gourl}/...

+

−

}

+

−

+

−

package() {

+

−

source /etc/profile.d/go.sh

+

−

mkdir -p "$pkgdir/$GOPATH"

+

−

cp -Rv --preserve=timestamps ${srcdir}/{src,pkg} "$pkgdir/$GOPATH"

+

−

+

−

# Package license (if available)

+

−

for f in LICENSE COPYING LICENSE.* COPYING.*; do

+

−

if [ -e "$srcdir/src/$_gourl/$f" ]; then

+

−

install -Dm644 "$srcdir/src/$_gourl/$f" \

+

−

"$pkgdir/usr/share/licenses/$pkgname/$f"

+

−

fi

+

−

done

+

−

}

+

−

+

−

# vim:set ts=2 sw=2 et:</nowiki>}}

+

−

+

−

Thanks to Rémy Oudompheng‎ for this one.

+

−

+

−

Add "|| return 0" after the {{Ic|go test}} line if you wish to force the test to succeed. It's recommended to report the issue upstream to the relevant developers instead.

+

−

+

−

==== Sample packages ====

+

−

* {{AUR|go-web}}

+

−

+

−

==== Troubleshooting ====

+

−

* If you get the error that there are two packages found, both package {{Ic|main}} and another package, try removing the corresponding .go file for the {{Ic|main}} package in the {{Ic|build()}} function. Alternatively, move it elsewhere when building and then copy it to {{Ic|/usr/share/doc/$pkgname/examples}} in the {{Ic|package()}} function.

+

−

+

−

=== Using ''go get''===

+

−

+

−

Here's another way that relies on {{Ic|go get}}. It can be nice to have if the {{Ic|go get}} method above doesn't work.

+

−

+

−

You probably won't need to modify the build() or package() functions at all, only the variables at the top (pkgname etc).

General guidelines

Naming

For applications written in Go, use the name of the application as the package name, in lowercase.

Be creative if the name is already taken.

For libraries written in Go, use go-modulename, in lowercase.

If the name already starts with go-, don't call the package go-go-modulename, but just go-modulename.

For PKGBUILDS that uses the "go" tool to download the package, only add "-git" to the package name if it's not built from a tarball or a from a tagged release (but from trunk/HEAD).

Similarly for mercurial packages, only add "-hg" to the package name if it's not a release-revision.

Extend this pattern for other version control systems.

The go tool has its own logic for which branch or tag it should use. See go get --help.

Consider adding the name of the author to the package name if there are several applications that are named the same, like dcpu16-kballardAUR.

In general, the most popular packages should be allowed to use the shortest or "best" name.

Postfixes to the package names (like -hg, -git or -svn) are optional if there are no official releases from the project in question. On one hand, it's common to use them when the package downloads from a VCS. On the other hand, most Go projects don't have any release-tarballs, only the repo which is used for branching/tagging the official release, if it's not trunk. Also, go get, which is the "official" way to install Go modules, uses the repositories directly. Use your better judgement.

Packaging

Go projects are either just library files, just executables or both. Choose the appropriate way of packaging them. There are several examples below.

Some Go applications or libraries have not been updated to the latest version of Go yet.

Running go build -fix may often work, but it may have to be fixed by the developer. Report an issue upstream if this is the case.

Several Go projects doesn't have a version number or a license file.

Use license=('unknown') and report an issue to the developer if a license file is missing.

Use version "0.1", "1" or the git-revision (or equivivalent for other version control systems) if the version number is missing.

Alternatively, use the current date as the version number, in this form YYYYMMDD.

Since Go applications are usually statically compiled, it's hard to envision reasons for packaging Go libraries instead of just Go applications.