Quoting Jeremy James (2022-02-11 14:59:06) > 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?
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 -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private
signature.asc
Description: signature
-- Pkg-javascript-devel mailing list [email protected] https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel
