Fix sanity file generation in Dockerfile (#610)

We no longer ship the sanify file as part of the SDK but
expect it be generated on first use:
  https://github.com/WebAssembly/waterfall/pull/656

Also remove the Dockerfile itself from the docker image if
we include it then whenever you change anything in the
Dockerfile it invalides all the layers and forces a
completely rebuild.  This makes iterating on the image
very slow.
This commit is contained in:
Sam Clegg
2020-09-10 16:14:40 -07:00
committed by GitHub
parent 81dd2232e1
commit bfdfd61656
2 changed files with 4 additions and 3 deletions

View File

@@ -4,9 +4,6 @@
# Allow to run the test script inside the Docker container # Allow to run the test script inside the Docker container
!/docker/test_dockerimage.sh !/docker/test_dockerimage.sh
# Allow the Dockerfile for future re-creation/reference
!/docker/Dockerfile
# Ignore unnecessary files inside top-level directory # Ignore unnecessary files inside top-level directory
*.bat *.bat
*.csh *.csh

View File

@@ -28,11 +28,15 @@ RUN echo "## Install Emscripten" \
&& echo "## Done" && echo "## Done"
# This generates configuration that contains all valid paths according to installed SDK # This generates configuration that contains all valid paths according to installed SDK
# TODO(sbc): We should be able to use just emcc -v here but it doesn't
# currently create the sanity file.
RUN cd ${EMSDK} \ RUN cd ${EMSDK} \
&& echo "## Generate standard configuration" \ && echo "## Generate standard configuration" \
&& ./emsdk activate ${EMSCRIPTEN_VERSION} \ && ./emsdk activate ${EMSCRIPTEN_VERSION} \
&& chmod 777 ${EMSDK}/upstream/emscripten \ && chmod 777 ${EMSDK}/upstream/emscripten \
&& chmod -R 777 ${EMSDK}/upstream/emscripten/cache \ && chmod -R 777 ${EMSDK}/upstream/emscripten/cache \
&& echo "int main() { return 0; }" > hello.c \
&& ${EMSDK}/upstream/emscripten/emcc -c hello.c \
&& cat ${EMSDK}/upstream/emscripten/cache/sanity.txt \ && cat ${EMSDK}/upstream/emscripten/cache/sanity.txt \
&& echo "## Done" && echo "## Done"