emscripten-core / emscripten-core/emscripten
Cache sanity file llvm as relative path from emscripten root
- Dominant language
- C++
- Stars
- 27.6k
- Forks
- 3.6k
- Avg merge
- 1d 1h
- Merged PRs (30d)
- 105
Description
Hi there,
A while back I completed my port to OpenBSD: https://github.com/osen/openbsd_emscripten
However during the process I had a couple of ideas that would make it easier to package and deploy.
I have created some build scripts that allow me to build a completely self-contained emscripten install (incl, binaryen, llvm, deps, etc). I personally prefer this approach to the emsdk. However there is pretty much one last thing I need, and that is to be able to move the directory around without needing to regenerate the cache.
So far the cache sanity file (to decide on cache regeneration) looks like:
`2.0.29|/home/jail/embuild/export/libexec/emscripten/llvm/bin|14.0|0x8195319f`
You may be able to tell from the path that my build system includes a llvm distribution inside the emscripten directory to encapsulate it and make it more "portable" (from a file system perspective).
The issue is that if I move this export directory around on disk, this will not match with the sanity file and it will all regenerate.
My current solution is to just set EM_CACHE in a wrapper script and allow each user of the package to generate their own, however it is a little messy (and wasteful). I would rather the cache to be within the emscripten folder along with everything else.
Is there some way that I can just ignore the check and use the cache regardless. I know for a fact that it will be suited to the rest of the toolchain because it is safely stored inside and not accessible by any other versions.
I have attached my emcc wrapper script so you can see the variables I am passing.
[emcc.txt](https://github.com/emscripten-core/emscripten/files/7178019/emcc.txt)
Apologies if this is confusing. I also understand it is a little different to how you guys are intending to package it.
Best regards,
Karsten
Contributor guide
Assessment
This issue has not been assessed yet.