-
Notifications
You must be signed in to change notification settings - Fork 3.4k
Build Target Compiler Option #1140
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
By build target do you mean It is useful in practice to run the same js in multiple environments, for me - node and spidermonkey shell, and web - without recompiling. We could add an option to hardcode it, but it would be small in terms of code size, I think? |
You're right, and I'm fairly new to emscripten so it may make an
|
It is just a few dozen lines of code, so i think it would be tiny in comparison to even a "hello world" program. Worth measuring though. |
Tested it with a hello world program using O2, the results arent as For simplicity's sake, this does not include inlining the print and On Fri, May 10, 2013 at 9:28 AM, Alon Zakai [email protected]:
|
Ok, thanks for the numbers, I guess we can close this then. |
) By default we still emit code that can run in node, web, shell, etc., but with the option the user can fix only one to be emitted. This also sets ENVIRONMENT to "web" if the user specifies an HTML output (emcc [..] -o code.html). In that case the indication is clear that the code should only run on the web. This is technically a breaking change though, as people may have tried to run the .js file outside of the web, and that may have worked in some cases. To prevent confusion, when ASSERTIONS are on we show an error if we hit a problem, and also in debug logging we mention doing HTML output setting the environment that way. The benefit to doing this is that it gets all the benefits of web-only emitting in a natural way for the main use case. For more details on the benefits, see #6542 #1140, but basically * When targeting only web, we don't emit node.js support code which includes require() operations that confuse bundlers. * We emit less unneeded code.
My apologies if this has been raised before, or is in the works, but I believe it would be beneficial to have the build target be an optional compiler parameter instead of being detected at run-time. This would remove the run-time checks, would remove code for the unused options (reducing file download size) and would allow inlining of the smaller functions eg print, printErr etc
The text was updated successfully, but these errors were encountered: