If emcc is run with --closure 1 then you receive an error that the
command '--max_old_space_size=8192' is invalid.

In fact, it attempts to run a command starting:
--max_old_space_size=8192 closure-compiler --compilation_level ...

Which appears to be caused by the 2009_closure-compiler.patch Debian
patch that modifies tools/building.py to create the following
function:

Hi Jeremy,

Quoting Jeremy James (2022-02-10 19:00:26)
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?

I am open to improving README.Debian, but will need help: Please provide
suggestions for rephrased text.


Kind regards,

 - Jonas

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.

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 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

Quoting Jeremy James (2022-02-11 14:59:06)

Makes sense now.  Thanks for elaborating!

I think a better approach is to simply set CLOSURE_COMPILER by default
and (build-)depend on closure-compiler.

Please consider sharing if you write a closure-compiler wrapper script -
might be sensible to ship with emscripten package, e.g. by setting
CLOSURE_COMPILER=/usr/share/emscripten/closure-compiler_wrapper by
default.

 - Jonas