[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: gnu: Add Go build system.
|
From: |
Petter |
|
Subject: |
Re: gnu: Add Go build system. |
|
Date: |
Fri, 16 Dec 2016 10:57:34 +0100 |
On 2016-12-16 03:05, Leo Famulari wrote:
On Sun, Dec 11, 2016 at 01:17:48AM +0100, Petter wrote:
+(define* (build #:key import-path #:allow-other-keys)
+ (system* "go" "install" import-path))
+
+(define* (install #:key inputs outputs #:allow-other-keys)
+ (copy-recursively "bin" (string-append (assoc-ref outputs "out")
"/bin"))
+ (copy-recursively "pkg" (string-append (assoc-ref outputs "out")
"/pkg"))
+ (copy-recursively "src" (string-append (assoc-ref outputs "out")
"/src")))
It looks like `go install` knows "where" to install the files, but
installs them in the wrong place, and then we copy them into place in
the install phase. I think it's inefficient to move the files twice.
Can the build phase use something like `go build`, followed by the
install phase using `go install` to move the files directly to the
package's output directory in /gnu/store?
The differences between `go install` and `go build` here is that `go
install` compiles and moves the result to $GOPATH/bin (unless GOBIN is
set to somewhere else).
`go build` compiles (always from source I believe) and leaves the
resulting binary in current directory.
`go install` compiles and also creates package objects in pkg/ which I
believe is a compiled object that is compiled once and then reused,
unless source is changed. Not sure if timestamps are used to determine
whether source has changed, and how that works on Guix.
Optimizations could be made for sure, I will look at this at
convenience.
On 2016-12-16 05:49, Leo Famulari wrote:
On Sun, Dec 11, 2016 at 01:17:48AM +0100, Petter wrote:
From 4c0597a95ae3cd111ef12d675edf501c559458ba Mon Sep 17 00:00:00 2001
From: Petter <address@hidden>
Date: Sun, 11 Dec 2016 01:10:09 +0100
Subject: [PATCH] gnu: Add Go build system.
* guix/build-system/go.scm: New file
* guix/build/go-build-system.scm: New file.
Another question: does this build system try to run tests? In my own
Syncthing packaging I used `go run build.go test`, but I noticed that
your Syncthing package built with this build system doesn't seem to run
the tests.
No. It only builds/installs at the moment. Tests, docs,
cross-compilation and other things (if there are more things), are not
dealt with at this point.
Note that Syncthing uses their own build program (build.go). This is
atypical. There will be a test phase, and Syncthing will override this
with their way of running tests.
Regarding cross-compilation. Go supports: 386, amd64, amd64p32, arm,
arm64, mips64, mips64le, ppc64, ppc64le and s390x as far as I can
tell. With mips32 being added in February. I have yet to discover how
the build system should deal with cross-compilations. The Go part is
easy, just set the GOARCH environment variable before compiling.
`GOARCH=mips64 go install ...`