Include sdk subprojects as wraps

[Nomura-RH]

Finally got this done...

Sdk subprojects are now out of the vcs, and have their own remote repositories. The only downside is we now have another postconf hack: paths to prebuilt .a files must be relativized for WSL and the MSYS environment.

[luckytyphlosion]

Regardless of whether the PR works or not, the idea of separating out the SDK sources to separate repos with patches to modify the SDK sources should be discussed with the other gen 4 maintainers (and probably pmd-sky too). The adoption of this is a huge paradigm shift in terms of how a user interacts with the SDK (e.g. being able to see all the SDK changes in the single repo, dealing with making changes via patches, needing to make duplicated SDK repos if users want to modify the SDK, needing to maintain a central repository for SDK sources -> possibility of single point of failure). Currently converted to draft until that is resolved with the other maintainers.

[mid-kid]

It's impossible to know what the fallout will be until something like this is merged. Compatibility should be ensured by pinning the commit hash, which means it'll always work (though it'd be nice to have a .lock file feature in meson), you don't need a fancy CI for that. Also, it's arguably easier to see sdk patches in a self-contained repo.

Worst case scenario only pokeplatinum ends up using it. Then we're back to square one and not any worse off than every repo having their own copy, which is the current situation. We do not need to coordinate all repos at this time.

[Nomura-RH]

Compatibility should be ensured by pinning the commit hash

Should I pin those before merging?

[luckytyphlosion]

Is it possible to merge this PR but keep the SDK sources here anyway, in case we decide against sdk subprojects as wraps so it's easier to revert?

[luckytyphlosion]

Might also want to hold off on this PR until the SDK is in a state that the pokeheartgold maintainers can agree on using. This would mean needing to go through each function, possibly renaming parameters and local variables, trying to find better matches, and general clean-up to be in line with the agreed upon style.

[Nomura-RH]

Is it possible to merge this PR but keep the SDK sources here anyway, in case we decide against sdk subprojects as wraps so it's easier to revert?

It would make no sense at all. Just don't merge at that point.

[Nomura-RH]

Might also want to hold off on this PR until the SDK is in a state that the pokeheartgold maintainers can agree on using. This would mean needing to go through each function, possibly renaming parameters and local variables, trying to find better matches, and general clean-up to be in line with the agreed upon style.

I don't see why we can't do this work while still merging this PR. If you're worried about the repo breaking, I can just pin the wraps to the current latest commits, which are known to be matching.

[luckytyphlosion]

Might also want to hold off on this PR until the SDK is in a state that the pokeheartgold maintainers can agree on using. This would mean needing to go through each function, possibly renaming parameters and local variables, trying to find better matches, and general clean-up to be in line with the agreed upon style.

I don't see why we can't do this work while still merging this PR. If you're worried about the repo breaking, I can just pin the wraps to the current latest commits, which are known to be matching.

It's just a question of how hard it would take to revert it in the future.

[Nomura-RH]

Might also want to hold off on this PR until the SDK is in a state that the pokeheartgold maintainers can agree on using. This would mean needing to go through each function, possibly renaming parameters and local variables, trying to find better matches, and general clean-up to be in line with the agreed upon style.

I don't see why we can't do this work while still merging this PR. If you're worried about the repo breaking, I can just pin the wraps to the current latest commits, which are known to be matching.

It's just a question of how hard it would take to revert it in the future.

Shouldn't be hard. Worst case scenario, instead of using git revert we just make a new commit that gets rid of the wraps and copies the subprojects back into our source tree. Nothing has to change inside the meson build files.

[luckytyphlosion]

Okay then do whatever.