Improve rebranding situation for binary addon building

[a1rwulf]

Description

This improves the ability to use binary addons in rebrands.

How Has This Been Tested?

Tested by building a rebranded version for Android.
See following repos for an example:
https://github.com/a1rwulf/xbmc/commits/addons-rebrand-testing
https://github.com/a1rwulf/pvr.iptvsimple/commits/Playa

Types of change

• Bug fix (non-breaking change which fixes an issue)
• Clean up (non-breaking change which removes non-working, unmaintained functionality)
• Improvement (non-breaking change which improves existing functionality)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that will cause existing functionality to change)
• Cosmetic change (non-breaking change that doesn't touch code)
• None of the above (please explain below)

Checklist:

• My code follows the Code Guidelines of this project
• My change requires a change to the documentation, either Doxygen or wiki
• I have updated the documentation accordingly
• I have read the Contributing document
• I have added tests to cover my change
• All new and existing tests passed

[AlwinEsch]

Is OK for me 👍.

As long there the addons manually becomes changed for 😄.
To have it here is OK, only to use then hack ways on addons to allow it without changes, would not good for me.

[AlwinEsch]

Maybe use then here also like on line 83, with:
include(${CORE_SOURCE_DIR}/cmake/scripts/common/Macros.cmake)

[a1rwulf]

Thx, I tried different other variables but somehow missed this one...

[a1rwulf]

Is OK for me .

As long there the addons manually becomes changed for .
To have it here is OK, only to use then hack ways on addons to allow it without changes, would not good for me.

Yeah - no plans to go any further with it.
I just think that our foundation should fully support changes of the app name.
Rebranders need to take care of getting their supported addons to work.

[a1rwulf]

jenkins build this with addons please

[a1rwulf]

@AlwinEsch most addons worked fine, so I assume my PR doesn't cause any breakage:
https://jenkins.kodi.tv/job/BuildMultiWithAddons-PR/60/

[a1rwulf]

I'll merge this soon if there are no objections.

[Rechi]

This doesn't improve the rebranding situation, it makes it worse. With this PR you have to change every binary add-on.

[a1rwulf]

This doesn't improve the rebranding situation, it makes it worse. With this PR you have to change every binary add-on.

That's not correct, you have to change every binary addon already.
But at the moment you need to patch our binary addon build system additionally because it's not prepared for rebranding at all.

[a1rwulf]

Example:
You change the APP_NAME in version.txt and build your rebrand.
On Linux this will install into /usr/local/lib/rebrandname and /usr/local/share/rebrandname.
However binary-addons look for /usr/local/lib/kodi and /usr/local/share/kodi.
So you end up with 2 situations:

• Build of binary addons complains cause it can't find the kodi package
• It accidently picks up all the items from your kodi installation, which is even worse

This PR makes sure it finds everything from your rebrand instead of mixing everything from kodi into the builds, which is an improvement already!

[wsnipex]

with this change every call to find_package(kodi) in addons will fail

[a1rwulf]

with this change every call to find_package(kodi) in addons will fail

Why?
If that would be the case, then the build with addons would have failed.
I've tested building kodi with an addon for android and the rebranded sample.
Both work.

[a1rwulf]

After internal discussion and some more digging.
IMHO searching for KodiConfig.cmake by binary addons is broken for linux because of:
https://github.com/xbmc/xbmc/blob/master/cmake/scripts/linux/Install.cmake#L39

[jenkins4kodi]

@a1rwulf this needs a rebase

[github-actions]

This pull request is now marked stale because it has been open over a year without activity. Remove the stale label or add a comment to reset the stale state.