Skip to content

Conversation

@sbc100
Copy link
Collaborator

@sbc100 sbc100 commented Oct 27, 2025

This is technically a breaking change so I mentioned it in the ChangeLog.

Fixes: #25663

@sbc100 sbc100 force-pushed the get_compiler_setting branch from 5a2713b to 1f2c4bc Compare October 27, 2025 21:09
@sbc100 sbc100 requested review from dschuff, juj and kripken October 27, 2025 21:09
@juj
Copy link
Collaborator

juj commented Oct 27, 2025

I'll defer to @kripken on this - I do not recall what the context was around adding this feature, and what the usage were.

Might be worth mentioning specific examples in the ChangeLog of which settings in particular will no longer be accessible, that people might have been referring to.

@sbc100
Copy link
Collaborator Author

sbc100 commented Oct 27, 2025

OK, will wait for @kripken to chime in

@juj
Copy link
Collaborator

juj commented Oct 27, 2025

that people might have been referring to.

The fact that the test code had OPT_LEVEL and DEBUG_LEVEL makes me ponder if those were some of the settings that the users were specifically interested in having. (It is a common motivation to add a test to specifically cover the feature that a user is interested in)

@sbc100
Copy link
Collaborator Author

sbc100 commented Oct 27, 2025

that people might have been referring to.

The fact that the test code had OPT_LEVEL and DEBUG_LEVEL makes me ponder if those were some of the settings that the users were specifically interested in having. (It is a common motivation to add a test to specifically cover the feature that a user is interested in)

I don't actually know if this feature has any users at all.

It was adding way back in 2014 but without much rational: 153f2d9

I can't find any users with google. There are some users on github .. I'll investigate more.

@sbc100
Copy link
Collaborator Author

sbc100 commented Oct 27, 2025

It looks like there are 14 users on github: https://github.com/search?q=emscripten_get_compiler_setting%28%22++NOT+path%3Aemscripten.h++NOT+path%3Aemscripten_get_compiler_setting.c&type=code

The settings used are EMSCRIPTEN_VERSION, PTHREAD_POOL_SIZE and LEGACY_GL_EMULATION.

Of these only EMSCRIPTEN_VERSION is an internal settings, so those 2 users would be affected. Maybe we should try to patch them to use runtime detection instead before we land this.

@sbc100
Copy link
Collaborator Author

sbc100 commented Oct 27, 2025

There are only two uses of EMSCRPITEN_VERSION in the above search and they are both actually same usage: save-editor/source/main.cpp. It also looks like the could both be replaced with __EMSCRIPTEN_xxx__ version macros at compile time.

So I think we should go ahead with this change. The other usages are using non-internal settings.

@sbc100 sbc100 force-pushed the get_compiler_setting branch from 1f2c4bc to 164083e Compare October 27, 2025 23:19
@sbc100
Copy link
Collaborator Author

sbc100 commented Oct 27, 2025

OK, I made a carve out for EMSCRIPTEN_VERSION here... so there should be minimal risk of breakages.

@sbc100 sbc100 force-pushed the get_compiler_setting branch from 164083e to 7d1df72 Compare October 28, 2025 20:37
This is technically a breaking change so I mentioned it in the
ChangeLog.

Fixes: emscripten-core#25663
@sbc100 sbc100 force-pushed the get_compiler_setting branch from 7d1df72 to da40019 Compare October 28, 2025 20:38
@sbc100 sbc100 merged commit 77a2bad into emscripten-core:main Oct 28, 2025
3 of 14 checks passed
@sbc100 sbc100 deleted the get_compiler_setting branch October 28, 2025 20:38
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

Successfully merging this pull request may close these issues.

RETAIN_COMPILER_SETTINGS should not retain internal settings

3 participants