ke 18. jouluk. 2019 klo 9.27 Gabriel Cuvillier ([email protected]) kirjoitti: > > My two cents on this, from the point of view of a daily Emscripten user on > various projects : > > If this change does not impact end-users of Emscripten, that just want to do > C++ development targeting WebAssembly, then this is perfectly fine. This > change would just be an EMSDK "implementation detail", and I agree that from > this point of view, removing the Java dependency is interesting.
For emsdk users this is indeed just an implementation detail, as emsdk install still sets up the SDK functionally like it used to. > An alternative suggestion: instead of having to rely on 3rd party > distribution system, why not "precompile/bundle" closure (as well as > minify-html, or any other 3rd party dep), and use a more classic CDN-approach > to deliver these big files. The reason for this is point #1 from the first post, and was discussed in https://github.com/emscripten-core/emsdk/pull/404#issuecomment-564720935, basically each update of closure would increase the size of the git repository by ~30MB/+13% overall download size. And since git tracks all history, that means it will download all old versions when one git clones. After a couple of updates of Closure, the size of all the Closures in the tree history would be a larger portion of the overall Emscripten git repository than Emscripten bits itself. Git LFS route would work for this only if Closure and html-minifier and other tools would provide a single file amalgamation of the whole toolchain they provide, but unfortunately this is not the case. Closure and html-minifier are split across hundreds of small files, so Git LFS cannot be applied. > This would remove the need for a package management system (npm, or even PIP > if you have the same idea for Python tools) running on users machine... and > potentially breaking for various reasons (network failures, misconfiguration > of PATH, weird interaction with system-wide installation of Node/npm, etc..) Only if Git LFS was feasible to avoid repository size bloat. Otherwise it would mean developing and maintaining support into Emsdk + its CDN backend to serve Closure and html-minifier etc. (which using npm helps avoid, points #2 and #4) Emsdk does provide a fixed version of Node.js for all platforms, so system-wide installations of Node/npm, and also PATH configuration, should not matter here. Network failures are a possibility, but that may be a bit of a FUD point - the robustness and reliability of npm infrastructure is likely better maintained compared to the robustness of emsdk infra. (there are probably 100x more active users of npm ecosystem compared to emsdk ecosystem) -- 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-2kMqBLJ%3D-3zjRFGTYM8yLOZOFx4ALhXrudWtXu-HyXNQ%40mail.gmail.com.
