From a36c6fb965152b8ecf3c0b0ebb7a6d51470d567f Mon Sep 17 00:00:00 2001 From: Yi Wang Date: Thu, 18 May 2017 14:12:25 -0700 Subject: [PATCH] Remove go.md and Grammerly README.md --- doc/design/build_system/README.md | 7 +-- doc/design/build_system/go.md | 98 ------------------------------- 2 files changed, 2 insertions(+), 103 deletions(-) delete mode 100644 doc/design/build_system/go.md diff --git a/doc/design/build_system/README.md b/doc/design/build_system/README.md index 4c4315d6b9b..310739f37ae 100644 --- a/doc/design/build_system/README.md +++ b/doc/design/build_system/README.md @@ -20,7 +20,7 @@ The difference between `nv_` functions and `cc_` functions is that the former us Both `nv_` and `cc_` functions enables C++11 (-std=c++11). -In addition, +Also, - to describe external dependencies, we need `external_library`. - to build shared libraries, we need `shared_library`. @@ -104,7 +104,4 @@ shared_library(api ### Implementation -As above example CMakeLists.txt executes, each function invocation -adds "nodes" to a dependency graph. It also use this graph to -generate CMake commands including `add_executable`, -`add_dependencies`, `target_link_libraries`, and `add_test`. +As above example CMakeLists.txt executes, each function invocation adds "nodes" to a dependency graph. It also use this graph to generate CMake commands including `add_executable`, `add_dependencies`, `target_link_libraries`, and `add_test`. diff --git a/doc/design/build_system/go.md b/doc/design/build_system/go.md deleted file mode 100644 index 90399ff7011..00000000000 --- a/doc/design/build_system/go.md +++ /dev/null @@ -1,98 +0,0 @@ -# Design Doc: `go_{library,binary,test}` - -## Concerns - -1. Need to build Go libraries callable from Go and from C. - - For usual Go libraries, the bulding command line is as - - ```bash - go build foo.go bar.go -o libfoobar.a - ``` - - For Go libraries callable from C/C++, the command line is - - ```bash - go build -buildmode=c-archive foo.go bar.go -o libstatic.a - ``` - - or for shared libraries: - - ```bash - go build -buildmode=c-shared foo.go bar.go -o libdynamic.so - ``` - - and `foo.go`, `bar.go`, etc must start with a line `package main`, - which defines all symbols in special pacakge `main`. There also - must be a `func main`, which could have empty body. - -1. Need to support building-in-Docker. - - We are going to support two ways to building -- (1) in Ubuntu, and - (2) in Docker container whose base image is Ubuntu. - - The challenge is (2), because to build in Docker, we run the - development image as: - - ```bash - git clone https://github.com/PaddlePaddle/Paddle -o paddle - cd paddle - docker run -v $PWD:/paddle paddle:dev - ``` - - which maps the local repo to `/paddle` in the container. - - 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. - - -## A Solution - -This might not be the optimal solution. Comments are welcome. - -### Directory structure - -We propose the following directory structure: - -``` -https://github.com/PaddlePaddle/Paddle - ↓ git clone - ~/work/paddle/go/pkg1/foo.go - /pkg2/bar.go - /cmd/cmd1/wee.go - /cmd/cmd2/qux.go - /github.com/someone/a_3rd_party_pkg (Git submodule to a 3rd-party pkg) - /golang.org/another_3rd_party_pkg (Git submodule to another one) - /build/go ($GOPATH, required by Go toolchain) - /src (symlink to ~/work/paddle/go/) - /pkg (libraries built by Go toolchain) - /bin (binaries bulit by Go toolchain) -``` - -Above figure explains how we organize Paddle's Go code: - -1. Go source code in Paddle is in `/go` of the repo. -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`. - -These rules make sure that all Go source code are in `/go`. - -At build-time, Go toolchain requires a directory structure rooted at -`$GOPATH` and having three sub-directories: `$GOPATH/src`, -`$GOPATH/pkg`, and `$GOPATH/bin`, where `$GOPATH/src` is the source -tree and the root of Go's `import` paths. - -For example, if `/go/pkg1/foo.go` contains `import -"github.com/someone/a_3rd_party_pkg"`, the Go toolchain will find the -package at `$GOPATH/src/github.com/someone/a_3rd_party_pkg`. - -In order to create such a `$GOPATH`, our build system creates -`/build/go`. Remeber that we want to make sure that all output files -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. -- GitLab