Skip to content

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

Closed
timmutton opened this issue May 5, 2013 · 5 comments
Closed

Build Target Compiler Option #1140

timmutton opened this issue May 5, 2013 · 5 comments

Comments

@timmutton
Copy link

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

@kripken
Copy link
Member

kripken commented May 6, 2013

By build target do you mean ENVIRONMENT_IS_* stuff?

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?

@timmutton
Copy link
Author

You're right, and I'm fairly new to emscripten so it may make an
insignificant difference, but it may be useful to remive unnecessary
content for a web build, where code/download size can be an important factor
On 07/05/2013 5:37 AM, "Alon Zakai" [email protected] wrote:

By build target do you mean ENVIRONMENT_IS_* stuff?

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?


Reply to this email directly or view it on GitHubhttps://github.com//issues/1140#issuecomment-17502966
.

@kripken
Copy link
Member

kripken commented May 9, 2013

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.

@timmutton
Copy link
Author

Tested it with a hello world program using O2, the results arent as
impressive as I had hoped. For a pure web build (not works), without using
closure it saves 2,841 bytes, with simple closure it saves 1,659 bytes and
with advance closure it saves 1080 bytes.

For simplicity's sake, this does not include inlining the print and
printErr functions that are generate in the environment blocks (although
closure may have ended up doing this), although I doubt that would make any
meaningful difference

On Fri, May 10, 2013 at 9:28 AM, Alon Zakai [email protected]:

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.


Reply to this email directly or view it on GitHubhttps://github.com//issues/1140#issuecomment-17696215
.

@kripken
Copy link
Member

kripken commented May 14, 2013

Ok, thanks for the numbers, I guess we can close this then.

@kripken kripken closed this as completed May 14, 2013
kripken added a commit that referenced this issue May 22, 2018
)

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.
axodox pushed a commit to axodox/emscripten that referenced this issue Mar 18, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants