Remove sanity checks?

[juj]

The Emscripten sanity check mechanism has been a bit inconvenient for a long time. One issue is that it adds up time to each build. The contribution is not big, but it's still a number of msecs for each tool invocation. Another issue is that the sanity check calls to java here, and on a clean OS X system, java is not installed, but /usr/bin/java contains a stub application which pops up a message dialog asking user to install it:

Closure compiler is kind of deprecated, and people don't need java installed to use Emscripten, so this is giving a misleading cue.

I'm thinking about setting emsdk based installs to always enable EM_IGNORE_SANITY=1 environment variable to skip this work. Although that still does check_llvm_version() and check_node_version() checks, which are redundant with emsdk since it installs all these tools at the same time. I'd like to bump up EM_IGNORE_SANITY to early out before those checks. @kripken: Any thoughts on that?

[dschuff]

I think this makes a lot of sense, and that we should maybe go even further and make sanity checks off by default (and instead perhaps just create a utility or flag to "just run the sanity check").

The sanity checks are not needed for someone using emsdk or another SDK-style packaging that includes the dependencies. I believe they are not needed for a user who installs emscripten via a system like APT or homebrew (which can express package dependencies, and can expect programs or libraries to be in known locations). So basically only those assembling all the pieces themselves need it, but that's a fairly small fraction of users, and they will need documentation anyway, so we can add the sanity checking mechanism to that documentation.

[kripken]

Sounds ok to me too. We could still run the sanity checks when EMCC_DEBUG is on, and when doing emcc -v perhaps, or add another flag as @dschuff suggests.

Specifically we can also just drop the java check entirely if it does that annoying thing on OS X (first I see it, does look bad I agree).

[hegdeashwin]

@kripken : As of now, is there any way to skip these sanity checks while compiling ? because my helloworld.c is taking lot more time to export helloworld.js/html

[kripken]

I think you can set EMCC_SKIP_SANITY_CHECK=1 in the env to skip the checks.

[atrosinenko]

On my incoming Emscripten installation, when I run the asm3.test_freetype test with EMCC_SKIP_SANITY_CHECKS=1 it finishes in 6 less seconds than without this option (what is about 6% of execution time). For asm1 variant of this test I have the same 6 seconds, but now it is about 8% of execution time (I just looked at final Ran 1 test in 75.139s line for timing information).

I think, that since the main approach to "batch-compiling" with Emscripten is through either emconfigure, emmake or tests/runner.py, then these tools may do the regular sanity check once every time right after the start and then set EMCC_SKIP_SANITY_CHECKS=1, supposing that sanity status will not change during the whole run. I think, that single check will not amount to 6 seconds. With this approach one doesn't have to fear of disabled sanity checks while not suffering from noticeable performance penalties. This does nothing with dependency on java, though. And I don't know what action is expected from these three tools (or there are some other?) if the check fails.

[kripken]

Good idea, yeah, in emmake/emconfigure (and also when emcc invokes itself, e.g. to build a port) we should set that env var, since the check has already been done.

[atrosinenko]

And what about the test runner? (I realize that sanity check in tests is forced by design, but is it by design to do sanity check on every compiler invocation underneath the runner.py, does sanity status depend on particular invocation?) And to try to implement this, I need to know what is expected behavior on check failure? I think, it is safer to exit with an error and a message like "If you want to skip the check, set environment variable EMCC_SKIP_SANITY_CHECK=1", because now it will not flood the console with hundreds of warning messages in red, but instead show lonely warning somewhere potentially far away from the point where user start to watch. Is it acceptable to sometimes fail unattended build on this warning this way?

[kripken]

Yeah, I think we can do the same in the test runner, except for test_sanity.py which checks this stuff. All the others can disable checks in their subprocesses. That should be a nice speedup I think.

I don't think we need to do anything special for failure of the sanity checks (before or after the proposed changes here) - such a failure is not likely, and hasn't been an issue in the test suite.

[stale]

This issue has been automatically marked as stale because there has been no activity in the past 2 years. It will be closed automatically if no further activity occurs in the next 7 days. Feel free to re-open at any time if this issue is still relevant.