Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Cache system libraries #6

Open
Algunenano opened this issue Jul 7, 2020 · 4 comments
Open

Cache system libraries #6

Algunenano opened this issue Jul 7, 2020 · 4 comments

Comments

@Algunenano
Copy link

First of all, thanks a lot for putting this out there; I've started using it today and it worked flawlessly in the first try.

This is not an issue but a feature request. It seems like the cache is being stored at the end of Run mymindstorm/setup-emsdk@v5, so system libraries built during the "normal" compilation are not cached.

In my test build, generating these libraries take ~1m 40s (out of ~2m). Extract:

Tue, 07 Jul 2020 12:11:04 GMT
cache:INFO: generating system library: libc.a... (this will be cached in "/home/runner/work/bq-tiler/bq-tiler/emsdk-cache/emsdk-master/upstream/emscripten/cache/wasm-lto/libc.a" for subsequent builds)
Tue, 07 Jul 2020 12:12:08 GMT
cache:INFO:  - ok
Tue, 07 Jul 2020 12:12:08 GMT
cache:INFO: generating system library: libcompiler_rt.a... (this will be cached in "/home/runner/work/bq-tiler/bq-tiler/emsdk-cache/emsdk-master/upstream/emscripten/cache/wasm-lto/libcompiler_rt.a" for subsequent builds)

Is there any way to setup a post run step to the build (either manually in each job or by adding an option to the action) to get those system libraries to also be cached? As far as I know, these generated system libraries only depend on the emcc version, so caching everything together should be safe.

@Algunenano
Copy link
Author

Algunenano commented Jul 7, 2020

In the end I was able to do this by using cache@v2 directly with something like this:

env:
  EM_VERSION: 1.39.18
  EM_CACHE_FOLDER: 'emsdk-cache'

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      - name: Setup cache
        id: cache-system-libraries
        uses: actions/cache@v2
        with:
          path: ${{env.EM_CACHE_FOLDER}}
          key: ${{ runner.os }}${{env.EM_VERSION}}
      - uses: mymindstorm/setup-emsdk@v5
        with:
          version: ${{env.EM_VERSION}}
          actions-cache-folder: ${{env.EM_CACHE_FOLDER}}
      - name: Build library
        run: make -j2
      - name: Run unit tests
        run: make check

With this the build step went from ~2m 10s to ~30 seconds.

Feel free to close this or incorporate it to the docs if you think it's worth it.

@mymindstorm
Copy link
Owner

Thanks for the request! I don't think that I can do much about this outside of adding to docs. I'm not aware of a way to cache things after the action finishes executing. I think more time can be saved if I have the action detect if the cache folder exists and not download from the cache if it isn't needed.

@Vogtinator
Copy link

Thanks for the request! I don't think that I can do much about this outside of adding to docs. I'm not aware of a way to cache things after the action finishes executing.

It's possible to run something as a post-run step by adding something like

runs:
  post: 'post.js'

to actions.yml.

@Vogtinator
Copy link

The approach from the README and #6 (comment) does not actually work.

If setup-emsdk did not hit the cache, it will use emsdk-main as directory in the build environment, but both setup-emsdk and actions/cache will only cache emsdk-cache, which contains a copy of emsdk-main before the build happens. Only if the cache was hit, emsdk-cache will actually end up with system libs inside.

I imagine it worked by accident during testing because setup-emsdk hit the cache once but actions/cache did not, so it was initially populated correctly.

@mymindstorm mymindstorm reopened this Jan 13, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants