Work in Progress - Cleanup and Improve binary add-on library handling

  Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Post Reply
ironic_monkey Offline
Posting Freak
Posts: 1,491
Joined: Nov 2013
Reputation: 71
Post: #16
i assume the idea with this layering of the API is to be able to have outdated addons work but with limited functionality ?
find quote
MrMC Offline
Posting Freak
Posts: 757
Joined: Jun 2014
Reputation: 31
Post: #17
While you are in binary addons area, you can nuke the wrapping for osx/ios. Legacy stuff that is no longer needed.
Also, nuke the versioning and symlink creations and treat it just like android that is, libXXXX.dylib. More legacy bits.
find quote
alwinus Offline
Team-XBMC Developer
Posts: 158
Joined: Aug 2008
Reputation: 4
Location: Mönchengladbach
Post: #18
Hi @ironic_monkey, yeah that's one of my main goal in mind. Will have the opportunity to extend this without the right all the add-ons have to be changed.

Using a Web browser a lot more is needed because the languages are to be used for Kodi. Furthermore, I want the opportunity to expand Add-ons in C ++ format to bring and eventually into the base "C" system has the chance to improve even integrate other languages.

Hi @MrMC, this with different Folder names and namespaces was on begin the most secure way for me to have them independent and related header text as small as possible. But thanks, I'll look at me when it's good to take it can be changed.

Also is in newest version no library needed anymore, the add-on access Kodi direct.

Has also done the first step of documentation for, visible here: https://github.com/AlwinEsch/kodi/tree/b...addon.api2
find quote
alwinus Offline
Team-XBMC Developer
Posts: 158
Joined: Aug 2008
Reputation: 4
Location: Mönchengladbach
Post: #19
Has updated my commits and reduced to one (now two Wink )
https://github.com/AlwinEsch/kodi/tree/b...b-rework-2

With the current changes for level two are only the following old headers on "./xbmc/xbmc/addons/include" needed:
- kodi_adsp_dll.h
- kodi_adsp_types.h
- kodi_audiodec_dll.h
- kodi_audiodec_types.h
- xbmc_addon_cpp_dll.h
- xbmc_addon_dll.h
- xbmc_addon_types.h
- xbmc_audioenc_dll.h
- xbmc_audioenc_types.h
- xbmc_pvr_dll.h
- xbmc_pvr_types.h
- xbmc_scr_dll.h
- xbmc_scr_types.h
- xbmc_vis_dll.h
- xbmc_vis_types.h

The new library headers are included also with the folder to this and no more on "./xbmc/lib/addons/

The last old headers are only for the work from Kodi to the add-on. The best way for me, to change them for API level type is after the new library comes in and the old becomes away to prevent conflicts.

Has updated also my commit to pvr.vdr.vnsi addon with this library rework, see https://github.com/AlwinEsch/pvr.vdr.vns...644ed97328
(This post was last modified: 2015-12-06 05:24 by alwinus.)
find quote
alwinus Offline
Team-XBMC Developer
Posts: 158
Joined: Aug 2008
Reputation: 4
Location: Mönchengladbach
Post: #20
Has worked a bit on the documentation for the binary add-ons.

Still not finished but visible to see what comes.
https://github.com/AlwinEsch/kodi/blob/b.../Readme.md

Not want to use the normal wiki from Kodi, I think there is more easy do change together with the related code and also is on code view the needed documentation always present.
The only point where I'm not sure is how the docs folder becomes handled.
- one way is to leave there
. - good = together with code
. - bad = a lot of commit messages to change
- and the other is to pass on github repository wiki.
. - good = prevent not needed commit messages
. - bad = That will forget an update again.
. - bad = Not possible for separate to the branches

Now the question to the add-on developers, is this way OK about documentation and better to leave in code?

Her on this small is the most finished:
https://github.com/AlwinEsch/kodi/blob/b...CPVRLib.md
(This post was last modified: 2015-12-08 06:37 by alwinus.)
find quote
Post Reply