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/CA%2B6sJ-2Kn8xdBHTMernXp4n_p31c3GW2ABKFoU39AUBY%2Bvck-A%40mail.gmail.com.
