The emscripten cache actually defaults to living inside of the emscripten
directory. The line where this occurs is `CACHE =
path_from_root('cache')`. Then `os.path.expanduser(os.path.join('~',
'.emscripten_cache'))` location is only used when the emscripten directory
is read only.
When using emsdk the cache location should always be
`emsdk/upstream/emscripten/cache`. emsdk also shipped with a
pre-populated cache so most system libraries are already built there.
For those who want to use a different cache location you can use the
`EMCC_CACHE` environment variable or the `CACHE` key in your emscripten
config file (both of these override the default). However, it doesn't
sounds like you need to do either of those things and the default location
inside the emsdk tree should work for you. Side note: emcc will also
using the $HOME location if the in-tree location is not writable. You can
set `EMCC_FROZEN_CACHE` if you want to accept this read-only location
(obviously new libraries cannot be placed there in that case though). See
https://github.com/emscripten-core/emscripten/blob/31f9fb3c71b1aacf5edf65e35515d41b59c10391/tools/config.py#L82-L92
.
cheers,
sam
On Mon, Oct 28, 2024 at 10:25 AM John Dallman <[email protected]>
wrote:
> Greetings, all!
>
> I have a somewhat unusual first project with Emscripten. I need to get a
> domain-specific C-like language generating WebAssembly. This is not too
> bad, because the DSL compiles into C code, which I then feed to the C
> compiler for the relevant platform. At this level, WebAssembly is "just
> another platform" but as always, the details are more complicated.
>
> I need to provide declarations for the platform's C run-time library
> functions, types, constants, and so on to the DSL. This is a fairly routine
> task, given the platform's C headers, but there are a few things about the
> Emscripten headers that are puzzling me.
>
> To forestall the obvious question, no, I can't just use the provided
> headers. The DSL is C-like, but has some syntax differences. Unlike C++,
> many C programs are not valid programs in the DSL, which gives much more
> freedom in the language design. It's a separate development that split from
> normal C in the mid-eighties and is still very much worth using for its
> specialised role. Yes, new hires have to learn it, which takes about two
> days for someone who knows C or C++. Learning about the specialised
> application area it is used for takes much longer.
>
> I'm running Emscripten on Linux. I started by looking at Emscripten
> 3.1.41, since that's the version used by a couple of other product teams
> that work on my site. That is fairly simple when I run a few emcc compiles
> with -H to get a report of what files are referenced. The top-level headers
> come from emsdk/upstream/emscripten/cache/sysroot/include. A few
> Clang-associated ones come from emsdk/upstream/lib/clang/17/include. That's
> all fine with me.
>
> Then I decided to check the latest emsdk, and found that with 3.1.69, the
> headers come from a different place. It builds a cache of the headers and
> other files it uses under ~/.emscripten_cache. The problems with that are:
>
> Storage: It will take 36MB in the user directory of everyone who ever
> compiles with Emscripten. We keep all our user directories on a server
> disk, because that's enormously convenient in many ways. But we really
> don't want to burn space with duplicates of that cache.
>
> Version lock: We need to be able to have several Emscripten versions in
> use simultaneously, by the same account, without conflicts. Our reason for
> this is that we plan to release products on WebAssembly, and from time to
> time, update the version of Emscripten we use, to get access to new C and
> C++ standards, compiler bug fixes, and so on. But we will not update the
> tools used to build a product version that's been released and is under
> maintenance, because we'd have to re-do a lot of the QA that we do at a
> release. So the service accounts that run our builds can't have caches of
> version-specific headers in their user directories.
>
> I need a way to tell Emscripten to put that cache somewhere else. I did
> some grep'ing of the Emscripten scripts, and found this line, in both
> 3.1.41 and 3.1.69:
>
> upstream/emscripten/tools/config.py: CACHE =
> os.path.expanduser(os.path.join('~', '.emscripten_cache'))
>
> I have not yet attempted to read the Python code and learn how it all
> works, because that could take ages; I don't know Python well at all and am
> not keen on it. I'm a naturally low-level programmer, much happier with
> assembly code than object orientation
>
> Is there an environment variable I can use to relocate that cache?
>
> Thanks very much,
>
> John
>
> --
> You received this message because you are subscribed to the Google Groups
> "emscripten-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected].
> To view this discussion visit
> https://groups.google.com/d/msgid/emscripten-discuss/CAH1xqgm39n%2B-%3DAeT09zJ38Bp3SMkiWk_TxMK0cEMcinnaaQn4w%40mail.gmail.com
> <https://groups.google.com/d/msgid/emscripten-discuss/CAH1xqgm39n%2B-%3DAeT09zJ38Bp3SMkiWk_TxMK0cEMcinnaaQn4w%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>
--
You received this message because you are subscribed to the Google Groups
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion visit
https://groups.google.com/d/msgid/emscripten-discuss/CAL_va2-imxQ2O0x3kKhpRvtanvYLRLEASCx2FrWUwy%3D2PxE94A%40mail.gmail.com.
