Consistent UI for debugging internal compiler issues.

[sbc100]

When emcc runs internal tools such as the JS compiler and the closure compiler we currently have different ways to enable the next level of debugging. We should probably decide on one of:

1. Recommend re-running with -sVERBOSE on the command line
2. Recommend re-running with EMCC_DEBUG=1 in environment
3. Recommend re-running with -save-temps
4. Always save temps somewhere in case of error (avoid re-running at all?)

Currently (1) is used for JS compiler and (2) is used for closure compiler, but (3) is the standard gcc/clang name.

[sbc100]

@kripken @dschuff @juj WDYT?

I think we should go with (3), or if we can find a way to make it work then (4) would be even better.

(Even if we go with -save-temps we can still enable this by default for users of EMCC_DEBUG and/or -sVERBOSE)

[juj]

I wonder if we could be as simple as using -v as a verbose flag?

Currently we transparently pass through -v from emcc to clang. I think it would be nice to output failing and warning preprocessed JS library output and Closure input to stdout if user passes -v (and hint to that extent). That is, the flag would do both?

If the canonical option isn't an env. var., I'd make EMCC_DEBUG=2 env.var. imply whatever setting we'd have, e.g. EMCC_DEBUG=2 would imply -sVERBOSE and/or -save-temps. It is nice to have some "give me all verbosity you've got" kind of an option.

Using -save-temps to save JS lib output/Closure input to disk sounds good as well.

[sbc100]

I think I slightly prefer -save-temps over -v because the meaning of -v in gcc/clang is to show the subcommands, not to save any temp files.

I totally agree that EMCC_DEBUG should enable the save temps.

(BTW, you you don't need EMCC_DEBUG=2 to debug closure issues today. I just use EMCC_DEBUG=1 and then it makes the error messages point to a temp file that is preserved.)

[sbc100]

Assuming we go with -save-temps as the user facing options for this, I propose the following plan of action.

1. Update closure compiler and JS compiler to honor -save-temps
2. Have EMCC_DEBUG enable save temps internally
3. Deprecate -sVERBOSE in favor of EMCC_DEBUG. The remaining uses of -sVERBOSE are, I believe largely for emscripten developer debugging which is that EMCC_DEBUG is for. We probably don't need a separate way to debug just the JS compiler only. Do we?

[juj]

I don't recall using -sVERBOSE for anything.

I'm ok with that plan. Though the stdout printing/dumping support does bug me a bit, I'd imagine there could be a day when I'd want to add EMCC_DEBUG=2 env. var. to a command that's running on the CI, and wish I could pull out the offending JS code that way, and not need a custom file upload/echo step to do that.. I suppose that could be added if/when that day comes.

[sbc100]

I don't recall using -sVERBOSE for anything.

Isn't it what you use for debugging JS library issue? Is the some other way to dump the pre-processed JS?

I'm ok with that plan. Though the stdout printing/dumping support does bug me a bit, I'd imagine there could be a day when I'd want to add EMCC_DEBUG=2 env. var. to a command that's running on the CI, and wish I could pull out the offending JS code that way, and not need a custom file upload/echo step to do that.. I suppose that could be added if/when that day comes.

I'm fine with EMCC_DEBUG=2 also dumping temp file contents to stderr or stdout. I never use EMCC_DEBUG=2 myself, only EMCC_DEBUG=1 and it seems reasonable for the former to be mega-verbose.