Problem
Java callers and the Clava-JS driver use different default roots for the same clang-dumper, CUDA, and AST-cache resources.
On Linux, direct Java use leaves CodeParser.DUMPER_FOLDER at its default:
/tmp/clang_ast_exe_<user>
CodeParser.DUMPER_FOLDER obtains that path from ClangResources.getDefaultTempFolder(), which calls SpecsIo.getTempFolder("clang_ast_exe").
Clava-JS overrides the same datastore key in Clava-JS/code/sideEffects.ts and follows the operating system's persistent cache convention. On Linux this is:
$XDG_CACHE_HOME/@specs-feup/clava
or, when XDG_CACHE_HOME is unset:
~/.cache/@specs-feup/clava
The two entry points therefore do not share downloaded clang-dumper releases, extracted includes, CUDA resources, or AST cache entries. This duplicates downloads and storage, and makes cache behavior depend on whether Clava was launched through Java or Clava-JS.
The Java default is also under the temporary directory while Clava-JS deliberately chooses a persistent user cache.
Open design question
Record and resolve which layer should own the default cache-root policy:
CodeParser and Java establish one platform-aware persistent default used by every frontend; or- each frontend supplies a root, but all official frontends obtain it from one shared policy; or
- the split remains intentional and is documented with a supported override.
The right migration and compatibility behavior still needs design work. This issue is intended to keep the mismatch visible until that decision is made.
Acceptance criteria
- Java and Clava-JS default behavior is either unified or explicitly documented as intentionally separate.
- The selected locations follow platform cache conventions and have a clear lifecycle.
--dumper-folder and programmatic DUMPER_FOLDER overrides continue to work.- Existing users do not unexpectedly redownload large resources without a migration or fallback policy.
Problem
Java callers and the Clava-JS driver use different default roots for the same clang-dumper, CUDA, and AST-cache resources.
On Linux, direct Java use leaves
CodeParser.DUMPER_FOLDERat its default:CodeParser.DUMPER_FOLDERobtains that path fromClangResources.getDefaultTempFolder(), which callsSpecsIo.getTempFolder("clang_ast_exe").Clava-JS overrides the same datastore key in
Clava-JS/code/sideEffects.tsand follows the operating system's persistent cache convention. On Linux this is:or, when
XDG_CACHE_HOMEis unset:The two entry points therefore do not share downloaded clang-dumper releases, extracted includes, CUDA resources, or AST cache entries. This duplicates downloads and storage, and makes cache behavior depend on whether Clava was launched through Java or Clava-JS.
The Java default is also under the temporary directory while Clava-JS deliberately chooses a persistent user cache.
Open design question
Record and resolve which layer should own the default cache-root policy:
CodeParserand Java establish one platform-aware persistent default used by every frontend; orThe right migration and compatibility behavior still needs design work. This issue is intended to keep the mismatch visible until that decision is made.
Acceptance criteria
--dumper-folderand programmaticDUMPER_FOLDERoverrides continue to work.