SCons: Refactor module defines into a generated header, cleanup #35963
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This supersedes #32453, which aimed at having all
MODULE_*_ENABLED
defines in a header to be able to do proper checks that modules are enabled before using them in other folders (especially inRichTextLabel
which usesRegEx
).It also supersedes #32781 and fixes #31011, allowing to compile with GDScript disabled again.
Those two could have been solved with less work via more custom defines, but the new approach was discussed as cleaner and overall more resilient with @punto- and @Faless. Having all the defines in a header allow us to only include this header where needed instead of passing hacks like
SVG_ENABLED
andFREETYPE_ENABLED
to the main environment.In the process of fixing this, we found that the removal of
env_modules.Append(CPPDEFINES=["MODULE_" + x.upper() + "_ENABLED"])
actually triggers linking order issues. I'm not sure why these defines prevented the issue, but after debugging with @Faless we found that the best is likely to ensure thatlibmodules.a
comes last on the linker command.There was then still one issue with
script_encryption_key
which is defined in a.gen.cpp
in core, and was thus part oflibcore.a
, triggering another linking issue. I made it a.gen.h
to solve it -- was there any reason for it to be a.cpp
and not a.h
in the first place?In a follow-up PR, I might add a few changes to split
libmodules.a
into multiplelibmodule_$name.a
, which should also remove the need for thesplit_libmodules
hack on Windows (#34227).