Build: PS2 / PPSSPP / AppIcon Fixes to pass all compile workflow checks

[rf2222222]

What does this PR do

Fixes PS2 paths to relative path
Fixes PPSSPP to compile on AppleTV (needs Apple TV MoltenVK to work on AppleTV)
Fixes AppIcon sizes to individual sizes (so it compiles on Azure Xcode 14.1)

Where should the reviewer start

How should this be manually tested

Any background context you want to provide

What are the relevant tickets

Screenshots (important for UI changes)

Questions

[github-actions]

Builds for this Pull Request are available at
Provenance-Lite.ipa
ProvenanceTV.ipa
Provenance-tvOS.ipa
Provenance-UnderDevelopment.ipa
Provenance-XL.ipa
Have a nice day.

[github-actions]

Builds for this Pull Request are available at
Provenance-Lite.ipa
ProvenanceTV.ipa
Provenance-tvOS.ipa
Provenance-UnderDevelopment.ipa
Provenance-XL.ipa
Have a nice day.

[github-actions]

Builds for this Pull Request are available at
Provenance-Lite.ipa
ProvenanceTV.ipa
Provenance-tvOS.ipa
Provenance-UnderDevelopment.ipa
Provenance-XL.ipa
Have a nice day.

[JoeMatt]

I see this has active pushes still so I converted to a draft PR.

Does this PR override the need for #2334 ?

[rf2222222]

I see this has active pushes still so I converted to a draft PR.

Does this PR override the need for #2334 ?

This adds code to get PPSSPP to compile on Apple TV (so Provenance Project compiles on build tests using appletvos), and for Play to compile on iOS (updates the hardcoded paths), on top of 2334. So.. this could just be pointed to merge into 2334, or it could be overridden — it’s up to you. =]

These are essentially fixes to get all the build checks to pass.

AppIcon in Assets using Single Size (the 1024x1024 image) was throwing an error, which is fixed by specifying individual sizes. A script to auto generate various sizes of icons on iOS/watchOS is added, along with different sizes in Contents.json inside AppIcon. With this, everything should now compile on all tests.

[github-actions]

Builds for this Pull Request are available at
Provenance-Lite.ipa
ProvenanceTV.ipa
Provenance-tvOS.ipa
Provenance-UnderDevelopment.ipa
Provenance-XL.ipa
Have a nice day.

[github-actions]

Builds for this Pull Request are available at
Provenance-Lite.ipa
ProvenanceTV.ipa
Provenance-tvOS.ipa
Provenance-UnderDevelopment.ipa
Provenance-XL.ipa
Have a nice day.

[github-actions]

Builds for this Pull Request are available at
Provenance-Lite.ipa
ProvenanceTV.ipa
Provenance-tvOS.ipa
Provenance-UnderDevelopment.ipa
Provenance-XL.ipa
Have a nice day.

[rf2222222]

Just FYI, I haven't merged this because it's part of a massive refactor branch I have. I'll push as soon as it builds though it will not have all cores activated in the build as I make spm projects for them.

I'm thinking about how to do the libretro cmake cores, eitehr using SPM's built in cmake support (not sure if it's good), or a custom XCode build action which I have experience with for custom build tools like we're doing with the cmake thing.

It will probalby just build the libs directly instead of making the xcode project, using cmake but for each platform and our shared MoltenVK path, and then link that to a swift / objc core in SPM.

So far I have all the C only cores building in SPM and I'm making progess through the non cmake C++ cores. It's not hard, just a lot of cores to copy boiler plate and fix paths.

the cores will be a lot more sane since they'll all be in the format

Sources/
Sources/PVFooCore (Current ObjC code, but changed to a category of the Swift subclass) 
Sources/PVFooCoreSwift (Subclass of Swift PVCore, using extensions)
Sources/PVFooCoreC ( C structs, enums, defines etc for use in Swift and ObjC )
Sources/libfoo (upstream project as a lib)

Cores can now be built without the app since all the PV* framewworks are seperate spm projects too.

In theory, you could make a thin wrapper app to just boot single cores / roms for testing

How’s the App Store release going? If there’s anything I could look at to get Provenance XL released on the App Store, let me know =]

[JoeMatt]

Just FYI, I haven't merged this because it's part of a massive refactor branch I have. I'll push as soon as it builds though it will not have all cores activated in the build as I make spm projects for them.
I'm thinking about how to do the libretro cmake cores, eitehr using SPM's built in cmake support (not sure if it's good), or a custom XCode build action which I have experience with for custom build tools like we're doing with the cmake thing.
It will probalby just build the libs directly instead of making the xcode project, using cmake but for each platform and our shared MoltenVK path, and then link that to a swift / objc core in SPM.
So far I have all the C only cores building in SPM and I'm making progess through the non cmake C++ cores. It's not hard, just a lot of cores to copy boiler plate and fix paths.
the cores will be a lot more sane since they'll all be in the format

Sources/
Sources/PVFooCore (Current ObjC code, but changed to a category of the Swift subclass) 
Sources/PVFooCoreSwift (Subclass of Swift PVCore, using extensions)
Sources/PVFooCoreC ( C structs, enums, defines etc for use in Swift and ObjC )
Sources/libfoo (upstream project as a lib)

Cores can now be built without the app since all the PV* framewworks are seperate spm projects too.
In theory, you could make a thin wrapper app to just boot single cores / roms for testing

How’s the App Store release going? If there’s anything I could look at to get Provenance XL released on the App Store, let me know =]

It's going. Cores are found but using an Objective-C category for cores didn't work. Swift doesn't see the methods. I'm writing a "bridge" class for swift to call into for cores that I don't want to convert to full Swift.

The branch develop-spm2024 has all the latest changes.

It builds with latest XCode in Swift 6 with concurrency! The app boots much faster now too.

Only the (AppStore) targets build on that branch at the moment.

What we need to do to get XL to be appstore compliant is convert the dylibs to .framework or frameworks.

I took a stab at it the other day and it starts to work, by making a dummy framework and linking them but it doesn't load Vulkan or the dylibs since the paths are wrong. I didn't go further since I had to get other builds out.

[JoeMatt]

The builds expired, i need to figure out how to get the build bot to rebuild.

I'm still working on the new branch but I'm getting close to porting all this over. I'm working on the LibRetroCore cores at the moment. Then the ones that make dylibs will need to be wrapped in a .framework for appstore uploading

[JoeMatt]

@rf2222222 this is an odd request, but can you push a dummy commit to trigger the builds. I lost access to my AWS that has the builds and they expired here.

I'll make a new site with the binaries but I can't trigger the build easily for some reason unless I do a new push, but i'd need to fork the PR for that

[JoeMatt]

Thanks @rf2222222 you rock.

I'm working on the the updated RetroCore now. I have about 2/3 of them done, doing the GLES ones next. We'll have something soon.

I'll probably need your help on a few items when it's done on my end.

I also need to repackage the dylibs as a .framework as the last step .

I think you'll like the new code. You can choose to either do work in Swift calling into a new 'libretro' clang module or defer to the objective-c code. For things like options, it's been much easier to do them in swift but for the A/V and I/O code I'm leaving most of it in objc

[github-actions]

Builds for this Pull Request are available at
Provenance-Lite.ipa
ProvenanceTV.ipa
Provenance-tvOS.ipa
Provenance-UnderDevelopment.ipa
Provenance-XL.ipa
Have a nice day.

[JoeMatt]

@rf2222222 the new PR handles this all now! Thanks for the amazing work.

I updated the retroarch code to codesign and load frameworks. Was an interesting experience lol

I even added a few new cores.

I'm leaving this open fore now since it has the ipas until the other branch builds with github.

Amazing work!