Switch to android-games-sdk-rs submodule?

[jb55]

As suggested by @MarijnS95, to ease maintainability of updating android-games-sdk, it would be ideal if we could use a submodule of android-games-sdk with our patches on top. This would allow us to continue to hack on the upstream files when we need to, and make it easier to rebase these changes on future versions of game-activity and game-text-input.

In:

• Update to gamesdk v4.0.0 with our rebased patches #189

I first had to revert all of the existing patches on top of 2.0.2, and then re-apply them on top of 4.0.0. To do this every time would be error prone and time consuming.

The downside of the submodule approach is that the android-games-sdk is like 200mb+, which is a bit crazy for a few files. This is an inconvenience but the revert and re-apply dance on every new version is also very annoying.

I've created https://github.com/jb55/android-games-sdk-rs with patches on top of v4.0.0. If a submodule is acceptable, I can rework #189 to use this approach, otherwise I will continue with #189 the way it is. @rib @MarijnS95

[rib]

hmm, submodules has rarely made anything better in my experience.

Most people don't remember or consider having to do the submodule init and so it becomes an annoying extra step whenever you clone a repo with submodules since they still aren't seamlessly integrated into Git.

This could have maybe been a bit easier without needing to do the explict revert of the existing game-sdk patches. It could have worked to first import a new snapshot of v4.0.0 and then re-cherry-pick the old patches that are still applicable.

Maintaining a games-sdk branch with our patches does sound good though - regardless of whether we then import that with a submodule.

Maybe we could have a submodule that is optional, that's useful when we do these periodic updates to the latest version, but when we're done we just copy the result in-tree so that 99.99% of the time anyone can just clone the repo and not have to think about git submodules.

Maybe we could tweak build.rs so that it can check for a third-party/game-sdk directory - or anything similar - and if it sees that the submodule has been fetched then that will take precedence.

That could then be used for development when updating the game-sdk, without imposing git submodules for others.

[rib]

One concern with even having submodules be used optionally for this kind of development is that cargo apparently doesn't have great support for submodules: rust-lang/cargo#7987

If the submodule is pretty large then an optional submodule might be annoying for anyone that wants to patch their android-activity dependency and fetch via Git.

[jb55]

I guess we can just copy the needed files over from the android-games-sdk-rs repo. at least now that the paths are aligned we can in theory patch things back and forth easier, and we still have the repo for rebasing patches.

[jb55]

I switch to a grafted version in:

• Update to GameActivity 4.0.0 #191

with instructions on how to update:

• https://github.com/rust-mobile/android-activity/blob/89600edb065a659968aeace44b1d5dd7d1d5f770/android-activity/android-games-sdk/README.md

[rib]

Since the current plan with #191 is to avoid adding a dependency on Git submodules (and we will instead import the small number of files we need from the games-sdk by copying them), then I think we can close this issue now.