Build dependency system for classes #49
Replies: 2 comments 1 reply
-
|
Basic internal dependency system is implemented in #54. The next step is to modify the build scripts so that sources of disabled classes are not compiled at all, which should speed up the build and optimize the resulting binary for size. For this to happen smoothly, the following must be done:
|
Beta Was this translation helpful? Give feedback.
-
|
This can be considered more or less feature-complete since #55. I've figured that using macros alone is sufficient for this. Also decided that there's no need to follow a strict convention of I'd say it's also worth adding |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Some classes cannot be currently disabled without introducing yet another build option, like with the current
LinkedListclass.Some classes also depend on functionality of other classes, like
ListNodeis essential forLinkedList, and must not be disabled.Extensibility and customization are the core development principles behind Goost development, so we need to make sure that most functionality can be easily enabled or disabled at build-time.
In theory, the various classes implemented in nested
modules/may also depend oncore/functionality.Note that the full list of classes is listed in the Goost API.
I propose introducing some kind of a dependency system to handle this at compile-time, which should be optional to use. The components system would be still relevant to conveniently enable or disable a collection of classes without accidentaly breaking dependencies.
A single manifest file could be created to configure what classes should be enabled or disabled in Goost. The dependencies themselves have to be explicitly declared in the existing root
goost.pyfor each class if needed.A manifest file can be written in Python, not JSON, as it would work better with the rest of the build system which is written in Python, in fact. The
custom.pycould be used for this purpose (#25), which is.gitignored currently. But it's also quite possible to introduce anothermanifest.pyscript.Example
manifest.pyconfiguration fileThere has to be a way to automagically disable compilation of classes according to a manifest. 🙂
The
manifest=path/to/manifest.pyshould likely be added as a SCons option in the module'sSCSub, because this is where component defines are generated.SCsubA similar approach at disabling all modules was also presented in godotengine/godot#41091.
See also godotengine/godot-proposals#1001.
Beta Was this translation helpful? Give feedback.
All reactions