Rework binary add-on system
Primary Goals;
- Bring backward compatible add-on systems
- Add related add-on developer documentation
- Rework headers to show only add-on related parts for development
- Reduce needed library program parts on add-on
- Is primary C++ and no malloc and free needed on add-on side for library, all strings using "std:
tring"
- Bring library systems more in coding style like on Kodi itself
- Together with change to cmake system from other developers becomes the add-on library removed and add-on calls Kodi direct
- Allow better code overview in kodi by separate library types independent.
Development branch:
https://github.com/AlwinEsch/kodi/tree/b...-rework-2/
New headers are present here, also is the start of the wiki for add-on developers visible:
https://github.com/AlwinEsch/kodi/tree/b...ns/include
PVR Add-on changed to new system (pvr.vdr.vnsi):
https://github.com/AlwinEsch/pvr.vdr.vns...api-level2
Parts to do:
- Cleanup
- Finish library related wiki
- Test on all add-ons for backward compatibility
- Change all add-on to new system (with backward can be don after merge in)
- Rework of add-on system itself to use API level system. Need done after merge in and all add-ons changed to new lib system
Ideas and comments are welcome.
NOTE: Reworked Thread start message to match last code changes.
(2015-11-03, 00:12)alwinus Wrote: [ -> ]...
- Make every class to a own header like in Kodi itself
...
Personaly I prefer this one, because I'm familiar with the Kodi code base and it's easier to find stuff.
If you want you could also move the enums to a separate header.
Thanks wisler,
moved now the enums to here:
https://github.com/AlwinEsch/kodi/blob/i...inations.h is then a better overview.
If also for the others Ok then I move the classes to own headers.
The major work is now done and starting now to separate to a own branch.
The only one bigger point to make is now to add a back compatibility way for older add-ons.
Bigger changes are done now and has updated the start message.
The biggest change is now that it allow backward compatibility to use add-ons with older API level versions together with newest. This reduce problems on API changes and is more time to update add-ons.
that sounds awesome, especially for PVR.
Changes becomes bigger and bigger
Currently I rework also the other libraries, with following parts:
- bring all type headers to new style
- remove libXBMC_codec.h and transfer function to libXBMC_addon.h (Only one function there and make no sense for me to have complete lib for it)
- remove libKODI_adsp.h and transfer functions to libXBMC_addon.h and libKODI_audioengine.h
- rename everything to with XBMC to Kodi
- as last step Cleanup Kodi's internal handle classes to reduce amount of same add-on library functions.
For Backward the old stays in.
One question about the way to handle exported add-on functions.
Is related to the removal of add-on to kodi interface libraries (libXBMC_addon-x86_64-linux.so ...) and to do the work direct inside Kodi (comes with cmake).
see
https://github.com/notspiff/kodi-cmake/c...2fe2e79525
Question is:
Pass all functions outside and open with "dlopen", like it is now there on changes?
Or another way, to pass only "Register" and "UnRegister" outside and do the rest over a function table, created from kodi?
OK latest news about the work:
Done:
- Over 200 changed files
- Basic rework of AddonLIB, PVRLIB and AudioEngineLIB done
- AddonLIB and PVRLIB partly tested (still possible to watch TV
)
- New header include only add-on developer parts
Parts still todo:
- Finish GUILIB rework
- Test and improve all libraries
- Add add-on system headers which depend to libraries (PVR and ADSP) to libraries itself (to have them together with API level changes)
- Rework all available binary add-on's to pass new system
One very good improvement seen on library rework
On my linux has never worked the exception handling for add-on libraries and has brought a crash from Kodi.
Now with the complete reworked system was the first time that it works correct with:
"AddOnLog: VDR VNSI Client: CallMenuHook - std::exception" and no Crash anymore.
Very awesome Alwin, can't wait to port adsp add-ons to it.
With the callback libraries comes it to the end and mostly now only documentation, cleanup and fixes on them.
There comes one of my next binary add-on goals where I want to ask.
Due to match of API level versions want I also include the add-on system functions inside them, e.g. xbmc_pvr_dll.h and xbmc_pvr_types.h to pvr.api2.
The easiest way is to use the same headers and system and moved there to lib.
But have the idea to use the add-on start complete independent for all systems. With them calls the add-on a "Register" function about his system and pass the needed functions with them to Kodi, which becomes then called.
The following parts see I as positive with them or brings more support for other add-ons:
- The binary add-on independent can be used for any system, e.g. Video or Music add-ons like them with Python.
- No more not needed functions inside add-on, only the required one.
- With all headers together in library prevent problems on changes, need then only a new level. And the old becomes only few translator functions to match new style (if it is not to big
)
- Better overview about needed header files
- Maybe improve this way also the segmention fault handling?
First I finish the libraries itself and then we can look about them. But want to ask now for plans in future.
One part for me is a way to have the add-ons on start independent to use them for all types and as base for other programming language add-ons.
Would it be ok to move this thread to the general development section? I'm sure other non-team devs like ironic_monkey have some valuable input in this discussion.