I've been confused about this for a long time...Can anyone clearly explain when the various API versions on modules and camera_info structures need to be incremented?http://chdk.wikia.com/wiki/Module_System is a start, but it's not really clear to me what specific fields need to change whenScenarios- Add a core function to to module_export list. No versions increment, because loading will fail if required function not present (?)- Add an exported function to a module. Minor version should increase in module exported API (e.g DNG libdng_sym?) What about the version in _module_info? If the core requires the new function, this is incremented in modules.c ?- Change signature of module exported function. Major version increases (?)- Change signature of a core exported function - How do we deal with temporary development branches ?
I don't know what the rationale behind it all is - and to be honest I don't really believe it's necessary.IMO the overhead to maintain it is more trouble than any benefit it might have.
Quote from: philmoz on 11 / March / 2013, 01:26:13I don't know what the rationale behind it all is - and to be honest I don't really believe it's necessary.IMO the overhead to maintain it is more trouble than any benefit it might have.Oh, there goes my "Get Phil to explain it all" plan Maybe this is a subject for the module v2 thread then. I agree the current system seems overbuilt and is quite hard to understand.In principle, it would be preferable to fail gracefully if the modules aren't compatible with the build, but if the system is too complicated to keep up to date, it doesn't really help.If there were 3rd party modules being distributed separately from CHDK, then it would be more of an issue. But even in that case, I'd be tempted to make a distinction between system modules (tightly integrated with the core code, like DNG, zebra, script languages) and third party standalone modules. I'd say that the former could be required to be exactly the same version as the core, while the latter could have a more limited, versioned public API.Another approach would be just to version it of the CHDK major version (1.1, 1.2 etc) with the development build assumed to be incompatible from version to version, and the release versions kept stable.
... and even camera platform id (can't see the need for this myself).
Quote from: philmoz on 11 / March / 2013, 04:03:28... and even camera platform id (can't see the need for this myself).Here's one example, but it's a rather special case. It expects functionality which is not available in any other port.That said, it's not possible to specify more than one P-ID, so the current way is not really optimal for every theoretical use.
Personally this is something I'd check in the _module_load function and display an appropriate message if it's not a supported camera. This could then work for more than one camera.
Started by RaduP Feature Requests
Started by eqltv General Discussion and Assistance
Started by axxcat LUA Scripting
Started by TobiMarg General Discussion and Assistance
Started by philmoz « 1 2 3 » General Discussion and Assistance