[Montellese]

I don't have access to the build slaves but I just changed a line in the xbmc-audioencoder-addons Makefile for testing and committed that as well.

[wsnipex]

that should do it

[Montellese]

that should do it

Yup that did it but obviously that's a rather hacky workaround

@Ned: Mind running the same tests again with an updated version? I didn't know if you needed 32-bit (http://mirrors.xbmc.org/test-builds/osx/...c-i386.dmg) or 64-bit (http://mirrors.xbmc.org/test-builds/osx/...x86_64.dmg) so I built both.

[Memphiz]

Having stale builds sucks! So basically what we need to do is to track the git revision of project/cmake/ subdir and if something changes there this always leads to a rebuild of depends aswell? This would need to be adapted accordingly in

https://github.com/xbmc/xbmc/blob/master...depends#L9
https://github.com/xbmc/xbmc/blob/master...depends#L5
https://github.com/xbmc/xbmc/blob/master...depends#L5

for each platform which uses depends (osx32, osx64, linux32(unusued atm), linux64, atv2, ios, rbpi).

Or even refactor that check out to a function in

https://github.com/xbmc/xbmc/blob/master...defaultenv

And use that in the platform specific scripts instead (this would allow us to change the trigger for rebuilding depends in one place).


But tbh i would find it better to move from projects/cmake to tools/depends/cmake because depends is already tracked by jenkins and if changing anything in cmake should result in rebuilding depends it should be located there imo. (i know this is a bad advice from someone who didn't follow the whole cmake approach - i bet not all changes in cmake would need a rebuild of depends...).

Well either of those will fix the issue.

[wsnipex]

well, the end game with binary addons has always been to get rid of always building them in depends.Instead build them seperately and make them available via addon manager.

[Memphiz]

So we need an extra buildstep script in jenkins for those?

[wsnipex]

ideally we'll have an extra jenkins build config for the binary addons. At least on linux you can already build them without xbmc/kodi core, which is the goal for all other platforms as well. Not sure if/when we'll get there, but it would finally decouple core from addons.

[Memphiz]

Yes that would mean restructuring jenkins to dependend jobs. I mean which (quick) solution should we do for now?

[wsnipex]

for now, just check if project/cmake has changed in addition to depends.

[Ned Scott]

well, the end game with binary addons has always been to get rid of always building them in depends.Instead build them seperately and make them available via addon manager.

This is a bit off topic, but I keep meaning to ask, will linux users eventually be able to install binary add-ons (PVR, audio, or anything else) via the Kodi GUI even if it's still handled via apt-get? Will it eventually be just zip files for all platforms? I've just always wondered how it will eventually work for the end user.

[wsnipex]

This is a bit off topic, but I keep meaning to ask, will linux users eventually be able to install binary add-ons (PVR, audio, or anything else) via the Kodi GUI even if it's still handled via apt-get? Will it eventually be just zip files for all platforms? I've just always wondered how it will eventually work for the end user.

We implemented this already >1 year ago, but our python based installer doesn't play nice with the internal python interpreter, so we'll have to look for another solution. No idea if any dev is interested in implementing a native C++ solution, e.g. via libapt or libpackagekit.

[Memphiz]

https://github.com/xbmc/xbmc/pull/5770

[Montellese]

@Ned: Any chance to run the same tests again with an updated version? I didn't know if you needed 32-bit (http://mirrors.xbmc.org/test-builds/osx/...c-i386.dmg) or 64-bit (http://mirrors.xbmc.org/test-builds/osx/...x86_64.dmg) so I built both.

edit by memphiz: fixed links

[Ned Scott]

Will do, once mirrors.xbmc.org is back up :)

[Kib]

Will do, once mirrors.xbmc.org is back up

Should be fine!