Catch-22: Running bootstrap.py requires Binaryen in config, but it's not there until having installed Emscripten

[juj]

I realize now my PR #1444 is botched up.

When run on a clean installation (git clone and then emsdk install sdk-main64bit), the bootstrap.py step fails, because it needs to see .emscripten_config generated to find Binaryen.

But .emscripten_config cannot be generated until the SDK has been installed and activated. Need to figure something else out.

For Unity use, we absolutely cannot have the bootstrap.py functionality at all: Emscripten will be installed into a read-only directory in the filesystem, so everything is frozen. So it is desirable to be able to have emsdk run bootstrap.py in some form during installation stage.

[sbc100]

Yes, the idea is the bootstrap.py is run only by those using emscripten directly via git and/or those producing binary packages.

The users of emsdk (or the unity equivalent) should not be expected to run the boostrap process because, by definition, they already have all the dependencies they need.

Do you use sdk-main64bit to produce the unity packages? Either way we should fix sdk-main64bit so that bootstrap gets run at the correct time. If needed we can try to make it so that bootsrap can be run without a valid config file. This requirement to be able to run certain tools even without a valid config file has come from a few other users too I think.

[juj]

Do you use sdk-main64bit to produce the unity packages?

Yes, that's right.

If needed we can try to make it so that bootsrap can be run without a valid config file.

That would be a good way I think. Do you recall off the top of your head what bootstrap.py is currently needing Binaryen for?

[sbc100]

Do you use sdk-main64bit to produce the unity packages?

Yes, that's right.

If needed we can try to make it so that bootsrap can be run without a valid config file.

That would be a good way I think. Do you recall off the top of your head what bootstrap.py is currently needing Binaryen for?

The problem is that simply importing shared.py or config.py requires that that config is read and validated. There is currently no separation of importing the code from running the startup code. I've tried to saparate these concepts over the years but never quite managed it.

Too many things depend on doing things like from config import CLANG which mean that the path to tools like clang need to be determined when config is imported. Making this change might be tricky.

The alternative change is to delay running of bootstrap until after we have a valid emscripten config file.. presumably emscripten depends (in the emsdk sense) on both binaryen and llvm, so those tools do exist at the time when you run bootstrap, but they just are not in a config file. Perhaps we could create a config file before we run bootstrap in emsdk.py? That soltuion might be quicker to get running.