As of Kodi 15.0 default addons use a dedicated cmake build process. They reside in `./project/cmake/addons`. These are for Kodi 15.0: audiodecoder.modplug audiodecoder.nosefart audiodecoder.sidplay audiodecoder.snesapu audiodecoder.stsound audiodecoder.timidity audiodecoder.vgmstream audioencoder.flac audioencoder.lame audioencoder.vorbis audioencoder.wav pvr.argustv pvr.demo pvr.dvblink pvr.dvbviewer pvr.filmon pvr.hts pvr.iptvsimple pvr.mediaportal.tvserver pvr.mythtv pvr.nextpvr pvr.njoy pvr.pctv pvr.stalker pvr.vbox pvr.vdr.vnsi pvr.vuplus pvr.wmc In addition for the live sources: adsp.basic adsp.biquad.filters adsp.freesurround I'm of the opinion that all of these should be optional since not everyone uses Kodi as a pvr. The question is which would be the best route to go. Should we build addons during the kodi build process or should we create a dedicated ebuild for them, e.g. ?
I should mention that none of these get built by default.
Should use at least separate USE flags even a separate USE var (via USE_EXPAND, like e.g. nginx does for its modules).
(In reply to Adrian from comment #2) > Should use at least separate USE flags even a separate USE var (via > USE_EXPAND, like e.g. nginx does for its modules). I'm not sure if `USE_EXPAND` is the correct approach since it seems to be meant for global usage where more than one ebuild might use such a variable. For my understanding variables like `LINGUAS` or `PYTHON_TARGETS` are predestined examples for a `USE_EXPAND` use case while `NGINX_MODULES_MAIL` is not. There exist dicussions on the dev mailinglist about that topic - see: - https://archives.gentoo.org/gentoo-dev/message/80ec8c1774c1a7d724a347012afcb421 - https://archives.gentoo.org/gentoo-dev/message/30fabe40da33c4cc9d46046339140b74 From https://devmanual.gentoo.org/general-concepts/use-flags/: "The USE_EXPAND list is set in profiles/base/make.defaults as of Portage 2.0.51.20. This must not be modified without discussion on the gentoo-dev list, and it must not be modified in any subprofile."
i'd prefer to avoid use flag expansion if possible we already have USE=pvr, so we can gate most of them how long do these take to build ? do they require external deps ? do they take up a lot of space ? if they're generally cheap/standalone, then i wouldn't worry about trying to put them behind USE flags.
(In reply to SpanKY from comment #4) > i'd prefer to avoid use flag expansion if possible > > we already have USE=pvr, so we can gate most of them > > how long do these take to build ? > do they take up a lot of space ? if they're generally cheap/standalone, then > i wouldn't worry about trying to put them behind USE flags. I can't tell since I didn't get my hands on them yet. But it looks like they tend to be rather small. > do they require external deps ? Yes they do, but it depends on the addon. From https://github.com/xbmc/xbmc/blob/master/project/cmake/addons/README: "Any dependencies of the addons must already be built and their include and library files must be present in the path pointed to by <CMAKE_PREFIX_PATH> (in "include" and "lib" sub-directories)." The repository I linked to does represent the cmake build system only: "This directory contains the cmake-based buildsystem for addons. It looks into the "addons" sub-directory and parses all *.txt files recursively. Each addon must have its own <addon-id>.txt file in a separate sub-directory which must follow one of the defined format: <addon-id> <git-url> <git-revision> <addon-id> <tarball-url> <addon-id> <file://path>" ...while each addon's sources live in a dedicated git repository, e.g.: audioencoder.flac -> https://github.com/xbmc/audioencoder.flac audiodecoder.nosefart -> https://github.com/notspiff/audiodecoder.nosefart pvr.dvblink -> https://github.com/kodi-pvr/pvr.dvblink adsp.biquad.filters -> https://github.com/kodi-adsp/adsp.biquad.filters Maybe it'd make sense to create individual ebuilds for each addon and name them schematically like media-plugins/kodi-addon-{CATEGORY}-{ADDON_NAME} - e.g.: ``` media-plugins/kodi-addon-audioencoder-flac ```
(re comment 4) The pvr use flag is no more for kodi-15.1, and that is what I want built. I've added "make -C tools/depends/target/binary-addons PREFIX=/usr" after "emake V=1" in src_compile() to make all the addons. This command can take a list, so it would seem sensible to make it work like apache's APACHE2_MODULES with a KODI_BINARY_ADDONS variable in make.conf to specify a subset of binary addons. Kodi itself should perhaps have a 'binary-addons' USE flag. It appears each addon downloads the source as it goes along, which seems to be not the gentoo way, though it will not download if the addon source has already been placed in the addons subdirectory. The binary addons need to be built with kodi (immediately afterwards in fact), which makes the idea in comment 5 unworkable.
Created attachment 410882 [details] Ebuild for platform This is the first step to building an addon for kodi
Created attachment 410884 [details] Ebuild for kodi-platform. The second step to making kodi addons.
Created attachment 410886 [details] Ebuild for kodi pvr.hts addon. Unfortunately this doesn't quite work, it seems something needs to be done to process pvr.hts/addon.xml.in to generate pvr.hts/addon.xml, but I haven't figured out what yet. During configure it produces: CMake Error at /usr/lib/kodi/addon-helpers.cmake:19 (FILE): file failed to open for reading (No such file or directory): /var/tmp/portage/media-tv/kodi-addons-pvr-hts-9999/work/kodi-addons-pvr-hts-9999/pvr.hts/addon.xml Call Stack (most recent call first): /usr/lib/kodi/addon-helpers.cmake:29 (addon_version) CMakeLists.txt:63 (build_addon) -- Configuring incomplete, errors occurred!
My comment 6 is all wrong, and the resulting ebuild fails to make any addons, with sandbox violations and the like. It appears to be impossible to build the addons within kodi, or at least I can't figure out how to do it. The binary addons are meant to be built after kodi has been installed. It looks more like the proposal at the end of comment 5 is the most feasible. I'm looking a something based on http://forum.kodi.tv/showthread.php?tid=220990&pid=1974620#pid1974620. I've made some ebuilds to get as far as building pvr.hts, but unfortunately it doesn't quite work. See the recent attachments.
I've found some more ebuilds pointed to in this kodi forum comment that may be a better start: http://forum.kodi.tv/showthread.php?tid=233276&pid=2071527#pid2071527.
Created attachment 411008 [details] media-tv/kodi-addons-pvr-hts ebuild compatible with kodi-15.1 The naming is all wrong, but this compiles an addon compatible with kodi-15.1. It shouldn't be called -9999. Pvr.hts commit 045bd71ae4204b958d1090f9edcba587edcbaced seems to breaks compatibility with 15.1, so I build from the previous commit. It appears that trying to fit kodi and it's addons into the gentoo scheme will be much harder without the addons using the same branching/tagging scheme as kodi itself.
(In reply to Peter Fox from comment #12) > The naming is all wrong, but this compiles an addon compatible with > kodi-15.1. It shouldn't be called -9999. According to https://devmanual.gentoo.org/ebuild-writing/file-format/ your example should be named as ``` media-plugins/kodi-addons-pvr-hts-0_preYYYYMMDD.ebuild ``` for a specific commit and/or branch since the repository (https://github.com/kodi-pvr/pvr.hts) does not provide any tags/releases and ``` media-plugins/kodi-addons-pvr-hts-9999.ebuild ``` for current master. Maybe in this case one could indeed consider the branch "Isengard" to be a tag - at least it seems that's what upstream is doing, branching instead of tagging, which then would give us: ``` media-plugins/kodi-addons-pvr-hts-15.0.ebuild ```
Note the add-ons are versioned, just not released... e.g.: https://github.com/kodi-pvr/pvr.vdr.vnsi/commit/3a7cd1b6ed840a32a1e35da48a2cd8a3ced8d02e#diff-f4f0722f6a223d077efc4eb144376536
kodi-16.0 doesn't appear to build/install these at all anymore do we really need to bother with writing ebuilds for these ? doesn't kodi's addon system work for people as-is ?
Can the addon system supply binaries like the pvr addons? Still provided by other distros: http://packages.ubuntu.com/search?suite=xenial§ion=all&arch=any&keywords=kodi-pvr&searchon=names https://aur.archlinux.org/packages/?O=0&SeB=nd&K=pvr&outdated=&SB=n&SO=a&PP=50&do_Search=Go
Ubuntu Xenial is still on 15.2, maybe the more interesting list is: https://launchpad.net/~team-xbmc/+archive/ubuntu/ppa?field.series_filter=xenial
(In reply to SpanKY from comment #15) > kodi-16.0 doesn't appear to build/install these at all anymore > > do we really need to bother with writing ebuilds for these ? doesn't kodi's > addon system work for people as-is ? I haven't been into Kodi for a couple of months. But from what I can read in the most recent README.linux (https://github.com/xbmc/xbmc/blob/master/docs/README.linux) is: "----------------------------------------------------------------------------- 4.4. Binary addons - compile ----------------------------------------------------------------------------- From v14 with commit 4090a5f a new API for binary addons is available. You can compile all addons or only specific addons by specifying e.g. ADDONS="audioencoder.foo pvr.bar audiodecoder.baz" .0 All addons $ make -C tools/depends/target/binary-addons PREFIX=/<system prefix added on step 4.1> .1 Specific addons $ make -C tools/depends/target/binary-addons PREFIX=/<system prefix added on step 4.1> ADDONS="audioencoder.flac pvr.vdr.vnsi audiodecoder.snesapu" ADSP addons: adsp.basic, adsp.biquad.filters, adsp.freesurround Audio decoders: audiodecoder.modplug, audiodecoder.nosefart, audiodecoder.sidplay, audiodecoder.snesapu, audiodecoder.stsound, audiodecoder.timidity, audiodecoder.vgmstream Audio encoders: audioencoder.flac, audioencoder.lame, audioencoder.vorbis, audioencoder.wav PVR addons: pvr.argustv, pvr.demo, pvr.dvblink, pvr.dvbviewer, pvr.filmon, pvr.hdhomerun, pvr.hts, pvr.iptvsimple, pvr.mediaportal.tvserver,pvr.mythtv, pvr.nextpvr, pvr.njoy, pvr.pctv, pvr.stalker, pvr.vbox, pvr.vdr.vnsi, pvr.vuplus, pvr.wmc Screensavers: screensaver.asteroids, screensaver.biogenesis, screensaver.greynetic, screensaver.matrixtrails, screensaver.pingpong, screensaver.pyro, screensavers.rsxs, screensaver.stars Visualizations visualization.fishbmc, visualization.goom, visualization.projectm, visualization.shadertoy visualization.spectrum, visualization.vsxu, visualization.waveform" So I'd say people need a large amount of these. Most of them used to be part of the core application prior to version 14.
Someone has made some effort to create individual addon ebuilds and a specific eclass. Maybe that'd help us to get a step forward: https://github.com/herrnst/gentoo-kodi-overlay
i just created and added kodi-platform-16* and kodi-pvr-hts-16* to the main tree. i noticed this bug just now after creating and adding them. anyway, the ebuilds i created work fine on ~amd64 with kodi-16.0. it also compiles on ~arm (i have kodi-16.0 ebuild adjusted for raspberry pi that i will provide soon). wrt the pvr add-ons, afaik these have to be compiled separately and are not part of the kodi add-on repository.
being tired of the "Update available"-msg when starting kodi i've copied kodi-16.0.ebuild to PORTDIR_OVERLAY/.../kodi-16.1.ebuild (and just commented out the line with the user-generated-addons) and emerged all the visualizations and the lame and vorbis-audio-encoder from this: https://github.com/herrnst/gentoo-kodi-overlay/tree/master/media-plugins (@hal:THX for pointing it out!) they all compiled and work.
I'm working on getting this done at https://github.com/gentoo/gentoo/pull/3195
