Given the development image `paddle:dev`, the following command builds PaddlePaddle from the source tree on the development computer (host):
```bash
docker run -v$PWD:/paddle -e"WITH_GPU=OFF"-e"WITH_AVX=ON"-e"WITH_TEST=OFF"-e"RUN_TEST=OFF" paddle:dev
docker run --rm-v$PWD:/paddle -e"WITH_GPU=OFF"-e"WITH_AVX=ON"-e"WITH_TEST=OFF"-e"RUN_TEST=OFF" paddle:dev
```
This command mounts the source directory on the host into `/paddle` in the container, so the default entry point of `paddle:dev`, `build.sh`, could build the source code with possible local changes. When it writes to `/paddle/build` in the container, it writes to `$PWD/build` on the host indeed.
...
...
@@ -110,7 +110,7 @@ Users can specify the following Docker build arguments with either "ON" or "OFF"
-`WITH_AVX`: ***Required***. Set to "OFF" prevents from generating AVX instructions. If you don't know what is AVX, you might want to set "ON".
-`WITH_TEST`: ***Optional, default OFF***. Build unit tests binaries. Once you've built the unit tests, you can run these test manually by the following command:
```bash
docker run -v$PWD:/paddle -e"WITH_GPU=OFF"-e"WITH_AVX=ON" paddle:dev sh -c"cd /paddle/build; make coverall"
docker run --rm-v$PWD:/paddle -e"WITH_GPU=OFF"-e"WITH_AVX=ON" paddle:dev sh -c"cd /paddle/build; make coverall"
```
-`RUN_TEST`: ***Optional, default OFF***. Run unit tests after building. You can't run unit tests without building it.
...
...
@@ -129,7 +129,7 @@ This production image is minimal -- it includes binary `paddle`, the shared libr
Again the development happens on the host. Suppose that we have a simple application program in `a.py`, we can test and run it using the production image:
```bash
docker run -it-v$PWD:/work paddle /work/a.py
docker run --rm-it-v$PWD:/work paddle /work/a.py
```
But this works only if all dependencies of `a.py` are in the production image. If this is not the case, we need to build a new Docker image from the production image and with more dependencies installs.
