Design Doc: New Building System #2187
Conversation
|
|
||
| go_test(api_test | ||
| SRCS | ||
| api_test.go |
There was a problem hiding this comment.
There will be a lot of go files to test, can we not manually add them? I think go test is a much more descriptive, maybe we can integrate it into cmake?
This should run all tests in current directory and all of its subdirectories:
$ go test ./...
This should run all tests with import path prefixed with foo/:
$ go test foo/...
This should run all tests import path prefixed with foo:
$ go test foo...
This should run all tests in your $GOPATH:
$ go test ...reference: http://stackoverflow.com/a/16353449/852385
There was a problem hiding this comment.
I think we should use ctest instead of go test to run tests in Go.
We can make go_test call
go test -c hello_test.go -o hello_test
doc/design/build_system/go.md
Outdated
| generated at build-time are place in `/build`. | ||
|
|
||
| Under `/build/go`, our build system creates a symoblic link `src` | ||
| pointing to `/go`, where all Go source code resides. |
There was a problem hiding this comment.
Add content in #2182 (comment) to this design doc.
| # api.go is changed, api need to be re-built. | ||
| go_library(api | ||
| SRCS | ||
| api.go |
There was a problem hiding this comment.
I think the library should be added by package, not by file.
There was a problem hiding this comment.
You are right -- Go toolchain can and can only build Go packages/binaries by packages, but not by files.
I verified this property by creating /tmp/a.go, which includes a function Add, and /tmp/main.go, which includes function main and run
cd /tmp
$ go build a.go -o lia.a
named files must be .go files
|
|
||
| go_test(api_test | ||
| SRCS | ||
| api_test.go |
There was a problem hiding this comment.
I think the test should be added by package, not by file.
doc/design/build_system/go.md
Outdated
| This assumes that all Go code, including third-party packages, must | ||
| be in the local repo. Actually, it assumes that `$GOPATH` must be | ||
| in the local repo. This would affect how we write `import` | ||
| statemetns, and how we maintain third-party packages. |
There was a problem hiding this comment.
statemetns -> statements
doc/design/build_system/go.md
Outdated
| 1. Each library package is a sub-directory under `/go`. | ||
| 1. Each (executable) binary package is a sub-directory under | ||
| `/go/cmd`. This is the source tree convention of Go itself. | ||
| 1. Each 3rd-party Go package is a Git submodule under `/go`. |
There was a problem hiding this comment.
There are many pros for using this submodule based solution:
- dependency version management is easy (by git hash).
- can modify dependency when doing experiments in the local filesystem.
Here are the cons that I can think of:
- Go import path support version control system like "git", "hg", "svn", (
go help importpath), but using submodule is limited on git. - need to manually add submodule for every dependency, when the dependency is already specified in the go source code.
I vote for the approach of set GOPATH to ./build/go and use go get to fetch dependency.
- more go idiomatic, dependency only specified in go source code.
- can still modify dependency when doing experiments in the local filesystem.
- if we want dependency management, we can use go community's spec and solutions: https://github.com/golang/go/wiki/PackageManagementTools
There was a problem hiding this comment.
Let us assume that we use Git submodule at the current moment, because this make 3rd party packages look like our own packages, thus doesn't block the development of our new building system.
We can go on learning Go's dependency versioning mechanism and redesign this later in necessary.
|
@helinwang I temporarily removed go.md and marked the work in #2210. |
Fixes #2154