[
https://issues.apache.org/jira/browse/CALCITE-1938?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16124449#comment-16124449
]
Francis Chuang edited comment on CALCITE-1938 at 8/12/17 4:28 AM:
------------------------------------------------------------------
For Go libraries, building a binary out of a library isn't very useful.
In Go, there is the concept of the GOPATH. It is an environment variable
pointing to a folder where you store and work on your Go projects. GOPATH
should contain the src/, pkg/ and bin/ folders. Projects are placed in `src/`,
for example `src/github.com/apache/calcite-avatica-go`. Executables are placed
in bin, and they are built by running `go install` in your project. Under
`pkg/`, you'd find the package binaries. They are intermediate objects that are
cached by the go tool. For example, if I run `go install` in
`src/github.com/some-org/some-project` to build an executable, and that project
imports a certain version of calcite-avatica-go, the calcite-avatica-go
dependency will be built as `src/github.com/apache/calcite-avatica-go.a`.
In Go, libraries are not shipped and built as binaries are they are not very
useful. The built binaries under the pkg/ folder are only temporary objects
cached by Go to improve build performance and they should be re-built during
the compilation of an executable.
The standard workflow is to use the dep tool or some third party dependency
management tool. It will check out the source into the project's vendor
directory, and if `go install` or `go build` is executed, it will build the
final binary.
>From my understand of maven and comparing with Go:
- Go does not need the clean step, as running tests or building does not create
temporary or binaries in the source tree.
- To test, we run `go test $(go list ./... | grep -v /vendor/)`. All this does
is tell the go tool to traverse the project for test files and execute them,
but exclude anything in the vendor/ folder because they contain the source of
our dependencies.
- Go install is not meaningful for a library. If the project produced an
executable, then `go install` can be used to build and place the binary into
GOPATH/bin. However, since calcite-avatica-go is a library, and there is no
main package in the code, it is not meaningful to build a binary.
In terms of developer instructions:
- If you want to contribute to the project:
- Fork it.
- Clone the official repo (github.com/apache/calcite-avatica-go) to
GOPATH/src/github.com/apache/calcite-avatica-go.
- Add your fork as a remote for in the cloned repo.
- Make changes, run tests using `go test`, commit and push to your fork.
- Merge on Github (if using apache gitbox), or have a committer fetch your
changes into a branch on the apache git repo and merge.
- If you want to use the library in a project:
- Install the dep tool (https://github.com/golang/dep) by running go get -u
github.com/golang/dep/cmd/dep
- Run `dep ensure -add github.com/apache/calcite-avatica-go`.
- Use the library in your project by `import`ing it and using it:
````
import _ "github.com/apache/calcite-avatica-go"
func main(){
db := ...
}
```
was (Author: francischuang):
For Go libraries, building a binary out of a library isn't very useful.
In Go, there is the concept of the GOPATH. It is an environment variable
pointing to a folder where you store and work on your Go projects. GOPATH
should contain the src/, pkg/ and bin/ folders. Projects are placed in `src/`,
for example `src/github.com/apache/calcite-avatica-go`. Executables are placed
in bin, and they are built by running `go install` in your project. Under
`pkg/`, you'd find the package binaries. They are intermediate objects that are
cached by the go tool. For example, if I run `go install` in
`src/github.com/some-org/some-project` to build an executable, and that project
imports a certain version of calcite-avatica-go, the calcite-avatica-go
dependency will be built as `src/github.com/apache/calcite-avatica-go.a`.
In Go, libraries are not shipped and built as binaries are they are not very
useful. The built binaries under the pkg/ folder are only temporary objects
cached by Go to improve build performance and they should be re-built during
the compilation of an executable.
The standard workflow is to use the dep tool or some third party dependency
management tool. It will check out the source into the project's vendor
directory, and if `go install` or `go build` is executed, it will build the
final binary.
>From my understand of maven and comparing with Go:
- Go does not need the clean step, as running tests or building does not create
temporary or binaries in the source tree.
- To test, we run `go test $(go list ./... | grep -v /vendor/)`. All this does
is tell the go tool to traverse the project for test files and execute them,
but exclude anything in the vendor/ folder because they contain the source of
our dependencies.
- Go install is not meaningful for a library. If the project produced an
executable, then `go install` can be used to build and place the binary into
GOPATH/bin. However, since calcite-avatica-go is a library, and there is no
main package in the code, it is not meaningful to build a binary.
> First Apache release for Avatica Go
> -----------------------------------
>
> Key: CALCITE-1938
> URL: https://issues.apache.org/jira/browse/CALCITE-1938
> Project: Calcite
> Issue Type: Bug
> Components: avatica-go
> Reporter: Julian Hyde
> Assignee: Francis Chuang
>
> Make a release for Avatica Go.
> Release number is TBD.
> This will be the first Apache release for Avacica Go, so expect more
> diligence / issues than usual.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
