Future maintainability

[libretro]

Future maintainability

[m4xw]

Hey @loganmc10 !
Big updates will be annoying/difficult to rebase (especially when files get moved), but that's what I came up with for now to minimize maintain efforts.
This wasn't really possible at all with your approach because of the "custom" files.

Some concept differences between your port and mine:
-Use git-subrepo for the "modules" instead of plain subtree
-Base code on the subrepos themselves
-No use of "custom" files beside external new files (honestly this was the biggest Issue IMO and why maintain effort went through the roof)

Some noticeable differences with that concept:
-We always know what we based on, in your port this was a major Issue.
Only you knew what commit the code was based on and we had no reference
Example
-Everything is streamlined by the git plugin, updating the code is a "git subrepo pull module/" away
-Everything can be pushed to a branch (subtree) for manual merges etc which helps managing all the code changes.
-There is a clear history of required changes from the core to the "libretro state"

Future Plans:
I talked with Gillou about that briefly, long term I'd like to upstream as much of the code as I can.
This includes:
-MUPEN64PLUSAPI Static
-Save/states logic (basically add a USE_GZIP) flag, optionally and some refactor so it can be used for libretro without libretro-specific changes (this can be useful for mupen too)
-Optional SDL (used by default)

I will create a PR and/or Issue after I cleaned everything up and have a clear overview of all involved changes, so that I then can get the opinion of the upstream team.

If you have any questions, tips or whatever, feel free to ask.

Also I am open for contributions if you feel like resuming some of your work ;)

I probably missed quite a few things, anyway, back to work.

[loganmc10]

Sorry I didn't mean "why didn't you do it my way" :) that obviously didn't work either. I guess the best approach would be to actually put whatever code is needed in the actual upstream repos and not have a libretro copy (like what was done with snes9x, although somehow a libretro copy still exists). I assume because of the architecture differences that probably won't happen though.

I just seems sort of pointless, GLideN64 and Mupen64Plus still undergo large changes now and then, this is sort of doomed to fall behind like it did before eventually

[m4xw]

I didn't understand it as "why didn't you do it my way".
My Idea was, as the former maintainer, I'd give you insight on the changes I am implementing and especially which points of your approach I improve(d)
Also git-subrepo is some black magic that fixes many Issues that come with the subtree approach.
But yes I agree, I need to get all non-libretro code upstream for this to work out properly long-term.
Anyway it isn't too much work for me in general, I got mupen-core and rsp ported in like 2.5 days and a few days hunting a retro_return but there is of course still lots to do, but given I establish a proper history now, rebasing will be far easier.
The update of the core that I am currently working on, could've been easily rebased with this approach.