Skip to content
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

Add option modules_enabled_by_default for shorthand disabling modules #41091

Merged
merged 1 commit into from Apr 16, 2021

Conversation

totlmstr
Copy link
Contributor

@totlmstr totlmstr commented Aug 7, 2020

Godot has frankly a lot of modules, only complicated further when adding custom modules, so disabling each of them by hand can get rather cumbersome. This PR adds in a shorthand form for disabling all modules, including overriding their default settings (such as mono's default disabled). It's intended to be an advanced, experimental debug option.

Side note: I had to add in some ifdefs in cpp files because those files did not compile correctly with the new option.


For example, if I wanted to test out bullet exclusively without compiling others because I (e.g.) modified something in bullet, I would have to do:

scons -j6 tools=no module_bullet_enabled=yes module_arkit_enabled=no module_assimp_enabled=no module_basis_universal_enabled=no module_bmp_enabled=no  module_camera_enabled=no module_csg_enabled=no module_cvtt_enabled=no module_dds_enabled=no module_denoise_enabled=no module_enet_enabled=no module_etc_enabled=no module_freetype_enabled=no module_gdnative_enabled=no module_gdnavigation_enabled=no module_gdscript_enabled=no module_glslang_enabled=no module_gridmap_enabled=no module_hdr_enabled=no module_jpg_enabled=no module_jsonrpc_enabled=no module_lightmapper_rd_enabled=no module_mbedtls_enabled=no module_mobile_vr_enabled=no module_ogg_enabled=no module_opensimplex_enabled=no module_opus_enabled=no module_pvr_enabled=no module_regex_enabled=no module_squish_enabled=no module_stb_vorbis_enabled=no module_svg_enabled=no module_tga_enabled=no module_theora_enabled=no module_tinyexr_enabled=no module_upnp_enabled=no module_vhacd_enabled=no module_visual_script_enabled=no module_vorbis_enabled=no module_webm_enabled=no module_webp_enabled=no module_webrtc_enabled=no module_websocket_enabled=no module_xatlas_unwrap_enabled=no 

This obviously gets even more complicated if I wanted to (e.g.) add in my custom module, enable it with bullet, and test it against that. In any case, the previous line with my new options becomes:

scons -j6 tools=no modules_enabled_by_default=no module_bullet_enabled=yes

Note: updated with module_bullet_enabled=yes instead of except_modules=bullet and modules_enabled_by_default=yes instead of disable_all_modules=yes and dev option.

Note that I added in dev as well, because one of the primary ways to effectively see if Godot works as is is to actually run the tests. Of course, in order to have the full effect of this PR to be realized, #40659 should be completed as well.

@aaronfranke
Copy link
Member

What about if the syntax was disable_all_modules=yes module_bullet_enabled=yes? I think if a setting is not set then the default can be an empty string, and if a module is set to an empty string the logic can set it to the inverse of disable_all_modules.

@totlmstr
Copy link
Contributor Author

totlmstr commented Aug 7, 2020

What about if the syntax was disable_all_modules=yes module_bullet_enabled=yes? I think if a setting is not set then the default can be an empty string, and if a module is set to an empty string the logic can set it to the inverse of disable_all_modules.

@aaronfranke With that in mind, that would make my except_modules mostly useless, since most people will probably force their modules like that but not use or forget to use the new option. (I can just imagine this happening quite easily.)

Should be straightforward to implement that instead.

@totlmstr
Copy link
Contributor Author

totlmstr commented Aug 7, 2020

@aaronfranke Ended up being just a simple try-except block. The placement had to be pretty specific, because of the env_base update.

This should be ready for reviewing and/or requests for more edits.

@totlmstr totlmstr changed the title Add option disable_all_modules for shorthand disabling modules Add option disable_all_modules for shorthand disabling modules Aug 7, 2020
@totlmstr totlmstr force-pushed the module-disable-edit branch 2 times, most recently from 93b59e1 to aa4b1cd Compare August 7, 2020 05:20
SConstruct Outdated Show resolved Hide resolved
SConstruct Outdated Show resolved Hide resolved
main/main.cpp Outdated Show resolved Hide resolved
@Xrayez
Copy link
Contributor

Xrayez commented Aug 7, 2020

I presume the use case of disabling modules is optimizing export templates for size?

Note that you can use custom.py and/or scons profile=modules_enabled.py option to make this easier (no need to use command-line for that currently). For a complete list of modules you can also look at .scons_env.json (only available once you attempt to build Godot) apart from --help which is easier to copy-paste and adapt into a Python script.

I confirm that with these changes, module_freetype_enabled=no works for compiling export templates (tools=no), but not for the editor: #28650. I think this deserve a separate PR as well, because it's a long standing issue. Besides there are already some modules which cannot be disabled as of now as seen in #39196. I'm also not sure whether it would actually work in release, yeah it does compile but what about run-time errors?

SConstruct Outdated
enabled = True
except:
if not env_base["disable_all_modules"]:
enabled = True
Copy link
Contributor

@Xrayez Xrayez Aug 7, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Without all those changes, modifying a single line seems to work too:

Suggested change
enabled = True
# Enable or disable modules by default.
enabled = not env_base["disable_all_modules"]

Copy link
Contributor Author

@totlmstr totlmstr Aug 7, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I originally thought that to be case, but (pointing out in your commit) mono's config.py will always override this setting with the code you have now, even if module_mono_enabled=true is set which leads to env_base being updated wrongly (notice that the configurations are being sent to env_base). On the same train of thought, I cannot do module_bullet_enabled=true for essentially the same reasons.

This led me to realize that I need to get the user input before that happens and skip over it.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah that's an idea behind my commit, I'm not sure if a user would expect this overriding behavior. For your PR this logic makes sense I think.

@Xrayez
Copy link
Contributor

Xrayez commented Aug 7, 2020

This PR adds in a shorthand form for disabling all modules, including overriding their default settings (such as mono's default disabled)

Do you suggest that using disable_all_modules=no would enable all modules? I think that's misleading.

I think we may have to play an explicit game and call this option modules_enabled_by_default=no (default would be yes as now).

I believe the module's config should decide for itself whether it's enabled or disabled by default as well. What if a module is forced to be enabled by default because the engine depends on it? (But yeah in that case such a module shouldn't be a module in the first place...)

@totlmstr totlmstr force-pushed the module-disable-edit branch 2 times, most recently from 39ba48a to 0c3d2c3 Compare August 7, 2020 20:39
@totlmstr
Copy link
Contributor Author

totlmstr commented Aug 7, 2020

Note that you can use custom.py and/or scons profile=modules_enabled.py option to make this easier (no need to use command-line for that currently).

On this point, I should have been a bit clearer, but I only intend for this to be an alternative option to enabling and disabling the modules themselves. Replacing the custom.py option in general is really "fixing something that isn't broken".

Do you suggest that using disable_all_modules=no would enable all modules? I think that's misleading.

I think we may have to play an explicit game and call this option modules_enabled_by_default=no (default would be yes as now).

@Xrayez I have been personally concerned about the naming scheme of the option, but before I change the name of it (and resolving the other changes), I'll do some more changes on this PR first.

@Xrayez
Copy link
Contributor

Xrayez commented Aug 7, 2020

Yeah, sorry for the wave of review, I'm sorta suggesting possible workarounds as well, it may take months before something can be merged in Godot, (depending on how big your changes are and the scope of those changes), I'm just a contributor, and the project manager is currently on vacation... 🙂

@totlmstr
Copy link
Contributor Author

totlmstr commented Aug 8, 2020

I'm not sure if a user would expect this overriding behavior.

I can just imagine a user complaining why their option is not being overridden themselves, even though the option itself does say explicitly that it disables them. 🤣

With that in mind, that makes my option...nicer(?), so changing the option's name to something nicer(?) is actually the better option.

@totlmstr totlmstr changed the title Add option disable_all_modules for shorthand disabling modules Add option "modules_enabled_by_default" for shorthand disabling modules Aug 8, 2020
@totlmstr totlmstr force-pushed the module-disable-edit branch 2 times, most recently from b61c329 to 2e0e2d1 Compare August 8, 2020 00:48
SConstruct Outdated Show resolved Hide resolved
Copy link
Member

@Calinou Calinou left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should be good to merge after applying the suggestion, rebasing then squashing.

This can be a good feature for contributors to make sure their newly added module doesn't accidentally depend on other modules.

SConstruct Outdated Show resolved Hide resolved
@aaronfranke
Copy link
Member

@totlmstr Any update? This would be nice to have, but this PR needs work.

@totlmstr
Copy link
Contributor Author

@Calinou @aaronfranke Apologies for the delay on this. I haven't had much free time lately to be able to focus on this, so things should be much smoother now.

Did that rebase, and, at least from my perspective, the Freetype errors I have previously seen in the repo are not present now (even did a fresh pull just to be sure, since it has been a while). I simply just reverted my edits in those unneeded files, since there is no need for those macros anymore. If there are no more edits needed, this can be merged pretty easily.

Copy link
Member

@aaronfranke aaronfranke left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Works for me with both debug and release builds of export templates. I also tested production=yes builds which fail, but it also fails on master, so it's not a problem with this PR.

@akien-mga akien-mga merged commit ce618d1 into godotengine:master Apr 16, 2021
@akien-mga
Copy link
Member

Thanks!

@akien-mga akien-mga changed the title Add option "modules_enabled_by_default" for shorthand disabling modules Add option modules_enabled_by_default for shorthand disabling modules Jan 5, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants