multiple issues found while creating `qri` command-line binary

[dustmop]

While doing the 0.8.2 release today, I encountered multiple issues. I was using the following command at first:

qri_build qri --qri ${GOPATH}/src/github.com/qri-io/qri --templates ${GOPATH}/src/github.com/qri-io/qri_install/qri_build/templates --platforms darwin,linux --arches 386,amd64,arm

Problems I ran into:

• What directory does this command need to run in? I thought I had made a recent change to make it not matter, but apparently it still does? I think there's some relative path being used to select the output directory, and the command will fail if not run from ${GOPATH}/src/github.com/qri-io/qri or ${GOPATH}/src/github.com/qri-io/qri_install/qri_build

• Where do output results go? It seems like they go to the ${PWD}/qri${platform}${arch}, but this is implied and never explicitly supplied by the user. If the output directory going to be implied, it should probably be in qri_install instead of ${PWD}.

• What is the "templates" directory? It seems to be a relative path, but I'm not sure what that directory is supposed to contain.

• Multiple flags, such as "qri", "frontend", "templates" default to a non-empty string, which is expected to be a relative path. Usually this relative path is not found, which eventually leads to a failure. If these flags are required, they should default to an empty string, and fail faster. In general, relative paths should not be allowed at all when we're building across multiple repos.

• How does readme.md get created? Something is using templates to fill in some values like the platform and architecture, but I couldn't figure out how this is supposed to work. For 0.8.1, many of the zip's contains readme.md files whose contents I could not track down in any of our repos.

• Why does the qri_readme.md in templates say "oh hai". It doesn't seem to properly turn into the readme.md in the 0.8.1 zips.

• If multiple values are given for platform and arch (using a comma-separated list), then multiple builds are begun in parallel using goroutines. But these build don't seem to be safe and independent. I got errors like

/usr/local/go/pkg/tool/darwin_amd64/link: running clang failed: exit status 1
ld: warning: ignoring file /tmp/go-link-493130558/go.o, file was built for armv7 which is not the architecture being linked (x86_64): /tmp/go-link-493130558/go.o

which makes me think that artifacts from one build are being linked into anther.

• If any platform or arch values are misspelled, there is no error, the build just continues with an impossible configuration. These values should be checked against a list of allowed options.

• Should the release version number be put in the zip output file? Some older builds did this, such as qri_darwin_386_v0.8.0.zip

• If there are any build errors, they get logged, but the failure is also swallowed. The return code from the process is always 0.

• Executables have their +x permission bits stripped off when added to the zips, so users that unzip these zips won't be able to run qri without chmod'ing. The fix here is to use zip.FileInfoHeader and zw.CreateHeader when copying the executable in order to preserve these bits.

• Windows build is broken:

  INFO[0000] $ go build -o qri_windows_386/qri
  go: downloading github.com/inconshreveable/mousetrap v1.0.0
  build github.com/qri-io/qri: cannot load github.com/inconshreveable/mousetrap: reading github.com/inconshreveable/mousetrap/go.mod at revision v1.0.0: unknown revision v1.0.0

  Might be a go module problem related to our current CI woes?

[dustmop]

Another thing to remember:

• Windows build of command-line qri should end in .exe.