On Mon, Nov 16, 2015 at 02:22:42PM -0800, Marvin Humphrey wrote: > 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.
Thanks for the feedback, Marvin. I plan on making this change later this evening. The primary motivation creating the subdirectory is the weird binary name. > 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. Chris
