It occurred to me that using a data structure might also be an alternate way to handle imports from the module. For raw_merge.c you have the librawop struct defined in the core code and filled manually from the import list in the module. If you move the struct into the module and have a pointer to it in the core code then you only need to import one item (the struct pointer).
Sounds reasonable. With API version check it is safe now. I prepare changes
You might also include the ModuleInfo stuff at the start of the struct as well - essentially a semi object oriented module approach / API.
Module info is detected by elf2flt as specific object. Pointer to it is in flat header. This allow to easy get complete information about any module. This is used by: module_loader(versions checks), module_menu(names/flags), fltdump. So it should be kept as separated specific object.
I've made three updates to the reyalp-flt branch for review
- module load changes to handle arrays and structs (patch1509_fltv6.txt from above).
- add camera_info structure to replace usage of camera.h #defines for portability (still some work to do with this)
I see no problem with camera_info on first look. But please wait a little. I would like prepare API version checks and post it to realp-flt before merge to main trunk.
This change also broke some modules compatibility.
- cleanup of the code that handles the CHDK 'gui' modes
Gui unification have a sense, although increase complexity of simple modes.
Some comments:
1) I think that mix setter with getter is always not good. This is surely bad style in C++/Java.
modinspect_old_guimode = gui_set_mode(&GUI_MODE_MODULE_INSPECTOR);
I do understand why you implement in this way, but maybe better implement get_get_mode_enum for enum comparisons?
2) I'm not sure isn't changing order of GUI_MODE_MBOX and GUI_MODE_OSD in gui.h broke logic of ixus310_elph500hs/kbd.c
3) Are changes in luascript.c (several functions registration removing) accident?
