Ok, sounds good. I'll test this as soon as it lands Thanks for the tip !
Le 15/12/2019 à 19:35, Jukka Jylänki a écrit :
In that CMake line I can see you are using Emsdk. For you this change would mean that instead of COMMAND "java" "-jar" "$ENV{EMSDK}/upstream/emscripten/third_party/closure-compiler/compiler.jar" you would issue COMMAND "$ENV{EMSCRIPTEN}/node_modules/.bin/google-closure-compiler" I.e. only the location of the closure-compiler file will change. Emsdk takes care of the npm install line, so emsdk installing a sdk will still come with Closure preinstalled and available. However the above path change is in some sense unrelated to this in-tree -> npm change, but instead a result of Closure getting updated to a newer version (which we want to do no matter what). In the newer version of Closure, java is optional. (google-closure-compiler executable will use it if available) su 15. jouluk. 2019 klo 17.37 Gabriel Cuvillier ([email protected]) kirjoitti:Hello, On CMake-based projects where I want to keep separate the web app code (= several vanilla JS files) from the various emscripten modules that are used (= several emscripten-generated JS/wasm), I conveniently use Closure as provided by Emscripten directly from my CMakefile to bundle/optimize the web app code. => CMakeList.txt is looking like: add_executable(<my_emscripten_module_1> file_1.cpp file_2.cpp --closure 1) # => my_emscripten_module_1.js/wasm add_executable(<my_emscripten_module_2> file_3.cpp file_4.cpp --closure 1) # => my_emscripten_module_2.js/wasm add_custom_target(<my_webapp_using_the_emscripten_modules> COMMAND "java" "-jar" "$ENV{EMSDK}/upstream/emscripten/third_party/closure-compiler/compiler.jar" "--js" "<file_1>.js" "--js" "<file_2>.js" "--js_output_file" "<my_webapp_using_the_emscripten_module>.js" "--language_in=ECMASCRIPT_2017" "--language_out=ECMASCRIPT_2017" "--compilation_level" "<BUNDLE|SIMPLE|ADVANCED>" DEPENDS <my_emscripten_module_1> <my_emscripten_module_2) # => my_webapp_using_the_emscripten_modules.js Then, to build the app, I just have to do: make <my_webapp_using_the_emscripten_modules> And pretty much, that's it, the 3 bundles are created: the web app code (closure optimized/bundled vanilla JS), the emscripten module 1 (closure optimized generated JS+wasm), and emscripten module 2 (closure optimized generated JS+wasm) I find this very convenient to do, as it allows to do everything from CMake, and without having to use another module bundler (Webpack, and co.) and the full node/npm ecosystem that I simply don't need. I admit it feels a bit old-school/an heterodox way of doing things on the Web (using Make!?), but I find this much more in spirit with the C++ way of building projects. After all, we are using Emscripten for a reason, isn't it ? But I suppose that scenario would be feasible also if Closure was provided through npm and not through a .jar directly in Emscripten distribution (I would have to call some npm command for this, right ?). I can live with a scary 'node_module' folder ;) Cheers, gabriel Hello all, the PRs https://github.com/emscripten-core/emsdk/pull/404, https://github.com/emscripten-core/emscripten/pull/9989, and https://github.com/emscripten-core/emscripten/pull/9990 propose migrating Closure compiler and html-minifier to reside outside the Emscripten tree, and be installed via npm. The benefits of this change are: 1. Future updates to closure and html-minifier will not bloat up the size of the Emscripten git repository (each update would increase the size of the git repository by ~+10% otherwise) 2. Emscripten developers do not need to maintain a CDN and code for distributing closure/html-minifier, easing CDN and testing burden from emsdk, 3. Tracking which version of closure and html-minifier we are on becomes explicit and idiomatic to people familiar with npm community (can be found in package.json) rather than having to look up git logs, 4. Updating versions become easier, as migrating to a new versions can be changed into the file package.json The drawbacks of this change are: 5. developers who follow the "I git cloned all repositories myself" approach and do not use emsdk need to run "npm install" once in the Emscripten root directory if they want to use closure or html-minifier, 6. If npm goes down, it will disrupt emsdk installation Can people think of other benefits/drawbacks that should influence this design change? Cheers, Jukka -- 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 on the web visit https://groups.google.com/d/msgid/emscripten-discuss/3e9f7095-dee6-711e-1623-ae715c81c5ce%40gmail.com.
-- 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 on the web visit https://groups.google.com/d/msgid/emscripten-discuss/1ed2587d-c550-8114-90b5-65aea2bbf5b3%40gmail.com.
