I’m currently working on building a snap for restic (backup program) which is distributed as a static binary on github. The author has setup a build.go file that does a ton above and beyond the traditional
go build main.go.
The real question here is:
- Should a person work through to get the app to build from source, or write the snapcraft.yaml to just wrap up the static binary?
My gut says build (future proofing). But wanted to confirm what others thought.
Now his instructions to build from source state to do something like:
$ go run build.go --goos linux --goarch amd64 # or $ go run build.go --goos linux --goarch 386
Reading over the snapcraft docs on the go plugin, there seems to be only a few options such as
go-packages, etc, and states that a package outside of
main wouldn’t be useful either.
I’m currently reading through the
build.go to decipher what it is actually doing.
Ultimately it seems like I need to find a way to run the above commands against the
build.go, yet account for
I noticed in an initial test build that it was pulling down golang 1.6 (by default, when I know the app needs >1.8. (was using a
cleanbuild environment). I know there is a V1.9 golang snap in the store. Is there a way to leverage that in my build process? Although I know go 1.8 is available via APT - so I could likely (assuming) set that as a build dep.
Sorry if this seems like simple questions, but my “devfoo” is not so great outside of basic stuff.
EDITED for additional info.