Suggestion: Dependencies bootstrap (Windows only?)

[kavika13]

I noticed that when installing emsdk, it contains its own version of Python, and that when using fips it had its own version of Ninja.

It might be possible to create a bootstrap to setup enough environment so that fips could do the rest. Python and CMake are the ones I can think of right now.

This is probably less of a concern on a system with a decent package manager (OSX/linux), but on Windows, this is several extra steps that are harder and might be useful to shortcut.

It also might reduce the burden of having the right versions installed system-wide. For example, I had Python 3 and had to jump through some extra hoops to fix a fips script so it would work with Python 3. (local hacks to fix the script mentioned in #184 - might do a pull request for that).

This probably wouldn't resolve the VS dependency, unless you wanted to go nuts and have a bootstrapped official compiler, too. This seems like it would be less flexible, though, and I think defeats some of what you're trying to do with different build options.

[floooh]

Hach yes, I agree, but it's a bit of a bottomless pit, at least when doing it right. I wanted to sidestep the issue with the fips diag tools command where fips basically checks whether it can find all the required tools, and if not give some hints what they are needed for.

I would rather improve this (for instance provide help how to get those tools), and make it more obvious somehow.

[pixelherodev]

Yeah, one thing I've noticed is that it might be helpful to have a single fips environment for global stuff such as SDKs and fips itself (though not project dependencies due to versioning issues), maybe in e.g. ~/fips

For instance, on my laptop right now I have over 6 GB spent just on the Emscripten SDK (three copies each at 2.2GB) - I was able to use symlinks to reduce that to 2.2 GB, but I can see how that would be a problem on Windows.

[floooh]

Maybe a better option would be to add an alternative fips setup emscripten command which points fips to an existing (globally installed) SDK instead of setting up a local version.

A long standing issue is to provide more control over the emscripten install anyway (e.g. defining a specific SDK version to use).

Another thing that's been rolling around in the back of my head is to provide an emscripten SDK in a docker image, and compile through that. Only problem is that Docker requires a Windows Professional or Enterprise version.