search for libretro system libraries

[Rechi]

This allows using libretro system libs.

[fetzerch]

I think we do have to make sure that the system wide installed version of the libretro core matches exactly the version that we're trying to package (git sha). The script extracts version information from the compiled libretro core as well as supported file system extensions and the setting the core supports.

If you just take whatever system version is installed, then kodi will show that game.libretro.x is installed in version 2.1.0 (with the settings that this version supports), while the actual provided version is something completely different.

Might be I'm overlooking something, but what's your idea of matching addon and libretro core version?

[Rechi]

The current solution also doesn't check the version it only matches because of assumptions.

[fetzerch]

I'm not in favor of the current solution either, don't even remember who implemented. Maybe @garbear himself? It does work reliably (and being it by assumptions). Also it would be fairly easy to write the git sha into the config file and check it in the CMakeLists.txt.

For the patch you're proposing, I have no idea how to ensure that the right version is picked.

If you think picking matching versions is not important, I'll not obstruct. But I fear that people will start reporting bugs for a specific addon version and we have no clue what's core version is in it. Do you have time to look into a proper fix?

[Rechi]

I have two solutions in mind

• check if version of the found lib matches the expected one
• set the lib version as addon version (and other info)

Which one would you prefer?

[fetzerch]

I'd prefer the first one. Could we fallback to compiling it if there's no matching version installed on the system?

[Rechi]

Either you want to compile with depends or system libs.

[Rechi]

With option one how would you handle cores which aren't versioned properly? Option 2 would allow to read all the info at compile time.

[fetzerch]

Most of them are not versioned properly. The version number typically reflects the version of the emulator. But all changes to make it a libretro core, bug fixes, ... is not reflected in the version number. The most reliable way would be the git sha. Packages from official libretro repos do contain the git sha in the version number. Can we read that somehow?

Option 2 would mean to reimplement quite a bunch of stuff from this project in cmake? reading versions, generating settings, ...

Always compiling the game addons is not an option? The libretro cores are somewhat different to other depends. It's the main addon code we'll be running. Not just for example an xml-library that doesn't impact the functionality or feature set too much.

[garbear]

Libretro version numbers are cosmetic, like the emulator name. They usually reflect the version of a past fork. They shouldn't be used in any versioning logic.

[Rechi]

Detecting the version is simple, but if you care about creating debian packages, the control file should set the correct libretro version requirements. I initially opened this PR to get rid of writing a config file for people who know what they are doing (e.g. LibreELEC). There is no version check and relying the config file doesn't assert that correct version is used too.

Always compiling the game addons is not an option?

In the current way they are pulled in, no, they are dependencies. If you always want to build them, the source code has to be imported into the game.libretro.* repos.

[coveralls]

Coverage remained the same at 78.447% when pulling 0148e5c028cac04921c806d31e7e225c3c67fcb9 on Rechi:findSystemLibs into 39162b68bb25516f2eb7199983bdbc525a42458f on fetzerch:master.

[fetzerch]

@Rechi you're right, I'll merge this and update the addons. Ensuring the right version is used is an extra step.