We have a bunch of ticket for DuckStation
#3381 #2904 #3372 etc
But DuckStation in Provenance doesn't actually build
It was being developed as a type of core where we could easily pull upstream, apply local patches if needed, and build as an Xcframeowork
This works in this core, similiar to some others, where we use the upstream projects CMake system, to make their ios "app" xcode project, then only link the generated .a's we need into our own PVCore code and wrap it
We have some other options.
- We could maybe do this whole thing using SPM instead of an XCode project
a. doing so may need some shared spm macros/build tools for external build systems?
- maybe we would maintain our own cmake file to make a cleaner spm or xcode project we can use directly?
- custom set of shell scripts or .patch files instead?
Ideally, i'd like to use swift package manager, have it easy to pull in changes from upstream project (so probably uses a submodule from upstream or our own fork we pull from and keep in sync).
If it uses libretro.h we can use either or both, PVThinLibretroCore would work if we build a .dylib locallay, but then we should just use the buildbot version, we could also use PVLibRetroGLESCoreBridge submclass, again, if we build a libretro.h version of the .a's from the cmake system or other,
Whatever works where, we'll probably start to do for other WIP cores, so this is a test bed and should maintain best practices and leave some flexiblity and re-use oppertunities for other core that are similiar hybid approach
we're trying to move more and more to SPM and easier ability to keep up to date with upstream core updates.
We have a bunch of ticket for DuckStation
#3381 #2904 #3372 etc
But DuckStation in Provenance doesn't actually build
It was being developed as a type of core where we could easily pull upstream, apply local patches if needed, and build as an Xcframeowork
This works in this core, similiar to some others, where we use the upstream projects CMake system, to make their ios "app" xcode project, then only link the generated .a's we need into our own PVCore code and wrap it
We have some other options.
a. doing so may need some shared spm macros/build tools for external build systems?
Ideally, i'd like to use swift package manager, have it easy to pull in changes from upstream project (so probably uses a submodule from upstream or our own fork we pull from and keep in sync).
If it uses libretro.h we can use either or both, PVThinLibretroCore would work if we build a .dylib locallay, but then we should just use the buildbot version, we could also use PVLibRetroGLESCoreBridge submclass, again, if we build a libretro.h version of the .a's from the cmake system or other,
Whatever works where, we'll probably start to do for other WIP cores, so this is a test bed and should maintain best practices and leave some flexiblity and re-use oppertunities for other core that are similiar hybid approach
we're trying to move more and more to SPM and easier ability to keep up to date with upstream core updates.