Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.Sign up
ENGINES: ALL: Split MetaEngines into 2 parts, statically link detection features across all engines. #2403
This PR splits apart the MetaEngines into a way that detection features are always available* to the executable.
This PR also extends the support for the same to all of ScummVM's engines (stable & unstable). Work for ResidualVM's engines is in progress and a PR for the same will be opened soon. It should probably get merged around the same time when ResidualVM syncs up with ScummVM.
(*Some engines fallback detection is not linked statically. More info in a bit.)
The format of each individual engine is largely similar to before, but I will explain in a bit how some things will change.
Changes to existing engines
Most changes are pretty simple to follow. The new structure will need to be kept in mind when working on new engines,
That's the basic engine split. As for the engines themselves,
Module objects / Building detection features
Some engines that would require review
Sci & Wintermute (fallback-detection)
Detection features as a plugin themselves
How is it done?
Modules objects / Building detection features for dynamic detection plugins
As always, any suggestions, improvements, or anything really, is appreciated and helpful.
DeepCode's analysis on #996dbd found:
I tested, it works nicely. Will start looking into the code deeper. These are the generic notes based on a cursory look and attentive reading of your comprehensive description above.
The PR got rot, again, sigh. I promise to merge it this week (if you have time to address my notes, of course).
First of all, I second @henke37 's opinion: the classic verb for is 'get', not 'give', thus,
Second, I was quite confused by naming of the MetaEngineConnect() and AdvancedMetaEngineConnect(). When reading your description and the code, it is not quite following their logic. E.g. you're asking to keep all
Then, regarding the complex fallback detection in Wintermute and SCI engines now. I do not like the proposed solution of loading the plugin for detection, as this would clash with the purpose of this whole exercise. However, we do really need trying detecting it. Thus, I would do it this way: Have a setting in
Putting detection into plugin does not compile.
Getting the following:
This is after my attempt to fix it, as previously it was
…es.h - Currently, it is empty. - After I enable engines one by to one to use detection statically, I will add them to the static_detect_engines array.
…n it. Note: No detection objects added currently. It's just an empty variable uptill now. - These DETECT_OBJS will be seen in action in the new commits - They contain engine_name/detection.o - They have MetaEngine code, which has detection features. - This way, Executable will have linked against the detection.o files - Detection.cpp files will be individually compilable and not dependent on engine
- MetaEngines will now always go to the executable. - But, because they still live in engine projects and are connected via a macro, they will need to be differentiated from Engines. - This macro, and it's use in future will help in that.
- Creating an instance of GLK requires searching through all sub-engine detection lists. - So, these must be there at the time of creating an instance of GLK. - Hence, all these objects will ONLY be skipped from static-detection, if GLK itself is static. - The above point is because it will need to avoid duplicate symbols.
- Using static for plugins will result in crash if the plugins are unloaded after being called for the first time. - Good example is when UncachedPluginMan uses these.
- The base class is temporarily named buildOptionsWidgetStatic.
- This allows apps that use create_project to build with statically linked detection features. - Also add support to write an addtional file - detection_tables.h inside engines/.
- The name was clashing with one of the audio files. - New changes were spread to the detection files, so no idea how this file is involved. - In the meanwhile, this commit should fix a build error, if any.
- No C11 support yet, revert to use map to fix build