On Fri, Nov 13, 2015 at 6:21 PM, Christopher Collins <[email protected]> wrote: > There is an unfortunate issue with the new newt path. When you run "go > build" or "go install" from the new directory, the resulting executable > has this horrible name: incubator-mynewt-newt.git, which is probably not > what you want. > > To work around this issue, you can pass the -o option to the build > command as follows: > > go build -o "$GOPATH"/bin/newt > > This will produce the properly named newt executable in the usual place. > > I think the correct long-term solution is to create a "newt" directory > in the git repository, and to move all the newt source files into that > directory. This is a fairly major change, so I wanted to give everyone > the weekend to think of reasons why this might be a bad idea.
+1 to make this change. Locating code within a strategically named subdirectory is also the approach taken by Apache Qpid Proton for their Go bindings and and that I'm taking with the Go bindings for Apache Lucy and Apache Clownfish. In those cases we're dealing with Go packages rather than executables, but the solution is the same. Arguably, this issue arises with any source repository that supplies multiple Go packages: you have to choose the names for the subdirectories according to what you want the import or executable name to be. Does it really matter whether the top level dir is unavailable because it is used by another Go package, because the project is polyglot and no language gets to claim the top level dir as its own (Proton, Lucy, Clownfish), or because the repo name produces a weird binary name (newt)? Whatever your reason for moving stuff to a subdir, using a subdir is a fine solution. I'd also like to comment on an unresolved incompatibility with regards to `go get` and Apache release policy. The `go get` command does not account for the concept of a release -- it always accesses version control directly, and it always deals with the `master` branch. This conflicts with Apache's concept that *only* released code can be advertised to those outside the development community. In time there's a good possibility that the matter will resolve itself, since people really like versions and the Go language maintainers idiosyncratic choice may prove unsustainable. But for the time being, Go projects at the ASF are in a weird space. Marvin Humphrey
