[OpenSauce04]

Guidelines

1. Rebase before opening a pull request
2. If you are sending several unrelated fixes or features, use a branch and a separate pull request for each
3. If possible try squashing everything in a single commit. This is particularly beneficial in the case of feature merges since it allows easy bisecting when a problem arises
4. RetroArch codebase follows C89 coding rules for portability across many old platforms check using C89_BUILD=1

Description

Currently, the make-frameworks.sh script makes the assumption that all supplied iOS core dylibs should have their platform set to IOS when running vtool. This makes sense and works perfectly fine when working with real iPhone hardware, but dylibs targeting the IOS platform are not binary compatible with iOS simulators. Apple's iOS simulators require the dylib to be built targeting IOSSIMULATOR instead, and if this is not respected, dlopen calls will fail. RetroArch doesn't currently handle this distinction, meaning that it is currently impossible to test RetroArch cores inside of an iOS simulator because cores will never successfully load, even if the core was originally built targeting the correct platform.

This PR addresses this by checking whether or not the current target is a simulator beforehand, and adjusting the argument passed to vtool accordingly. This is achieved via a new variable VTOOL_PLATFORM, which takes the place of PLATFORM; this is because PLATFORM is a widely used name throughout the rest of RetroArch, and the new VTOOL_PLATFORM variable functions differently from the former, and may contain different values. Using a new variable name instead reduces confusion.

Even though it is no longer used in the script, I have left PLATFORM as it is just in case it is needed in the script at some point in the future.

I have also applied the same fixes mentioned above to tvOS.

Reviewers

@warmenhoven

[OpenSauce04]

I have found an additional issue, will convert to a draft for a moment while I look into it...

It seems like there's an upstream bug in MoltenVK which is preventing any cores from actually running due to an unrelated rendering crash, but they do load. That issue is entirely unrelated to what's being addressed in this PR, which is simply getting the cores to load at all, so this PR can probably be freely merged pending a fix for the other issue in MoltenVK. I will report the problem upstream.

[OpenSauce04]

I have absolutely no idea how the changes in this PR correlate to the metal-harness failure. Looking into it
After requesting a re-run, the test passed without issue. Must've been a fluke. Re-opening for merging.