[alwinus]

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.

[AchimTuran]

...
- 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.

[alwinus]

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.

[alwinus]

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.

[da-anda]

that sounds awesome, especially for PVR.

[alwinus]

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.

[alwinus]

AudioEngine lib is already partly done
https://github.com/AlwinEsch/kodi/tree/i...oengine-v2

[alwinus]

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?

[alwinus]

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

[alwinus]

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.

[zag]

Great work! Keep it up

[AchimTuran]

Very awesome Alwin, can't wait to port adsp add-ons to it.

[alwinus]

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.

[Montellese]

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.

[alwinus]

OK from my side