[cmake] addons support multiple regex arguments for ADDONS_TO_BUILD

[fuzzard]

Description

Currently if supplying multiple arguments for ADDONS_TO_BUILD that include a regex

ADDONS_TO_BUILD='game.libretro.* peripheral.joystick'

The regex will not match or be processed at all.
You currently need to explicitly set each if you include multiple arguments

ADDONS_TO_BUILD='game.libretro.2048 game.libretro.mrboom peripheral.joystick'

Motivation and Context

Playing with libretro addons, found that a regex isnt used if supplied in a multi argument addons_to_build

How Has This Been Tested?

Mac OS building multiple combinations of selective arguments

ADDONS_TO_BUILD='game.libretro.* peripheral.joystick'

exact match of game.libretro and peripheral.joystick, regex match of game.libretro.mrboom, game.libretro.2048

ADDONS_TO_BUILD='game.libretro peripheral.joystick'

exact match of game.libretro and peripheral.joystick, regex match of game.libretro.mrboom, game.libretro.2048

ADDONS_TO_BUILD='pvr.hdhomerun pvr.argus* peripheral.joystick'

Exact match of pvr.hdhomerun and peripheral.joystick, with regex match of pvr.argustv

This also highlights an existing behaviour regarding the core game.libretro. You cannot selectively only build game.libretro as all other game.libretro.* automatically match with the cmake if check. This behaviour does not change with this PR.

xbmc/cmake/addons/CMakeLists.txt

Line 259 in 2d7e977

elseif(id MATCHES "${ADDONS_TO_BUILD}")

I think the easier way to resolve this would be to rename game.libretro to something like game.libretro.core. I couldnt come up with anything easy to handle this case, and game.libretro is the only case i could find this happens to across any binary addons. No other active binary addon, has the name that is a subset of other active addons

Screenshots (if appropriate):

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

[phunkyfish]

Nice change. Tested locally, works well.

[AlwinEsch]

Your changes are good to have for such cases 👍.
Thanks for this.

[wsnipex]

looks good