> Yes, this is a known issue, documented in README.Debian:
> https://salsa.debian.org/js-team/emscripten/-/blob/debian/latest/debian/README.Debian#L50
> ...
> Thanks for the suggestion. I wonder if such change will actually be any
> better: I very much doubt that the horribly old closure-compiler
> available in Debian can do *anything* sensible, but would be happy if
> proven wrong.
>
> Did you test that suggested change, using closure-compiler in Debian?
Well, it certainly can't be worse - this error is caused by the debian
patch! But yes, the packaged closure-compiler from 2013 is somewhat
unsuitable for use generally. In this case, I was hoping to create a
/usr/local/bin/closure-compiler script and use that instead.
If I install that package and explicitly set CLOSURE_COMPILER to
/usr/bin/closure-compiler then I get the inevitable following:
building:ERROR: Closure compiler run failed:
building:ERROR: "--language_out" is not a valid option
If I grab a recent closure-compiler JAR [1] and create a wrapper script:
cat >/usr/local/bin/closure-compiler <<EOF
#!/bin/sh
java -jar /usr/local/lib/closure-compiler-v20220202.jar "\$@"
EOF
chmod +x /usr/local/bin/closure-compiler
And explicitly set that with CLOSURE_COMPILER, then that seems to work fine.
> Sounds like you have some knowledge/experience here.
To be fair, I'm just trying to get this working for some automated
builds rather than getting deep into the internals of emscripten, but
I really would prefer not to have to create custom versions of tools
like emscripten if at all possible. For example there's another
frustrating issue for parallel builds that it always wants to create
~/.emscripten even if --generate-config is used but that's upstream
and I'll send a bug to them (I do, however, want to use the debian
feature of automatically setting CLANG_ADD_VERSION/LLVM_ADD_VERSION to
save having to install the llvm-defaults related packages).
> I am open to improving README.Debian, but will need help: Please provide
> suggestions for rephrased text.
I would suggest updating the arguably faulty patch to just have the
following for tools/building.py's get_closure_compiler() (optionally
fixing the upstream comment typo):
--
def get_closure_compiler():
# First check if the user configured a specific CLOSURE_COMPILER in
thier settings
if config.CLOSURE_COMPILER:
return config.CLOSURE_COMPILER
# Otherwise use the system-shared one
return ['closure-compiler']
--
And then it would actually call closure-compiler and it might just
inspire somebody more au fait with the respective packages (and how to
approach such a problem) to address the 16 or so reverse-dependencies
of closure-compiler mentioned in #916145?
Best wishes,
Jeremy
[1] https://mvnrepository.com/artifact/com.google.javascript/closure-compiler
