You can use Git LFS and commit zipped directories, and then during the emsdk installation process unzip them.
On Wed, 18 Dec 2019 at 22:04, Jukka Jylänki <[email protected]> wrote: > 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 > . > -- 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%2B_KjGZxDc1YTSPjL-qCTZig13xf_pazZRO5KBAjH8x%3Dt1%3Dquw%40mail.gmail.com.
