Move sdl2_ttf, sdl2_image, sdl2_gfx, sdl2_mixer in features

[Cobrand]

Related to #233, but I'm creating a new issue for this cause I don't want to bump everyone in the other (chances are that after a year without any discussion, they wouldn't be as interested anymore)

cc @AngryLawyer for your approval

Why ?

When a release / a version bump is published in this crate (rust-sdl2), breaking changes sometimes have to be updated in sdl2 modules as well. Moving everything here as optional features would allow propagating the changes to the modules directly in a single commit, instead of having an awkward period where the modules (sdl2-ttf, sdl2-image, ...) would be stuck as a deprecated version of sdl2 because the modules weren't updated as the same time as the commit.

Another problem is that any version bump requires a PR / a change from the modules crates, which is starting to become cumbersome for such inactive crates.

This change would be planned before 1.0.0, and would allow this crate to have all these modules as optional and disabled by default features.

How ?

This part raises some questions, and I must say I am rather inexperienced with such git manipulations, but subtrees would probably be the best choice here. As I said, I have never user anything like that, so any help is appreciated.

These sdl2 modules would then be converted as features (Rust-wise) and made disabled by default.
Updates to the documentation will be required as well.

We already have the approval from @xsleonard, but ideally it would be best to have the approval of @andelf as well. Technically, we could do without it and proceed without its consent, since its crates are under MIT and we can use them as we please as long as we keep the licenses and the authors, but it would obviously be best if we could have its approval and its opinion on the topic as well.

What about sdl2-net ?

Rust offers a very nice API for close to metal tcp and udp protocol; in addition with other crates such as serde and bincode, tcp / udp transmissions can be a breeze, and thus sdl2-net is not required in any Rust adaptation of one's code.

License

This crate and every module mentioned is licensed under MIT. @cmr opened an issue on sdl2_ttf to relicense the crate under MIT/Apache-2.0, and if needed we can license only the subtree sdl2_ttf under MIT/Apache-2.0 while licensing the main crate under MIT only.

[AngryLawyer]

I'd definitely be up for this; the difficulty is the herding of cats part of it.
Like you, I've got no idea how subtrees work, though.

Historical digression: this SDL2 library started when I really wanted to use SDL2 while only SDL1 libraries existed - the support libraries just sorta popped up around it and other people started using it.

[AngryLawyer]

I'm ambivalent about sdl2-net, but the completionist in me likes the idea of getting the whole set.

[andelf]

up for this! better for these crates to be in one repo.

[AngryLawyer]

Nice one. I guess it's time to do some reading on submodules. Also, we need to decide on opt-in or opt-out for using them.

[Cobrand]

Submodules are different from subtrees, and we can't use submodules in that case. I think subtrees are usable though, I've looked it up and it looks appropriate.

[AngryLawyer]

Sorry, yeah, I meant subtrees. Not nearly enough coffee today.

[Cobrand]

From what I've understood, it would basically look like this:

.git/
examples/
    demo.rs
    ttf/
        demo.rs
    ...
src/
    video/
    surface/
    ...
    ttf/
        .git/
        mod.rs
        ffi.rs
    image/
        .git/
        ffi.rs
        ...

That would mean keeping the git history in every submodule, and "cutting" part of the subrepos (everything that isn't in src/, meaning Cargo.toml, LICENSE, ..., but examples/ as well). Useful directories such as examples will have to be moved to the central repo, but unfortunately we'll lose the history on that part (not that it matters that much).

[Cobrand]

Actually there's no need for a fancy command such as git-subtree, we can just cp the others trees directly into sdl2, and the git history will be kept for every submodule, but the history for each module until now will not be visible in the main git repo. I will take care of that. (After 5 minutes of testing this isn't possible, we'll keep subtrees)

I'll be pushing changes from time to time in another branch

[AngryLawyer]

I'm not all that good at the more complex parts of Git; this doesn't mean that we'll be subsuming the other Git repos, will it?

[Cobrand]

Depends on what you mean by subsuming, but concretely that means that we won't "merge" the others, they have their own history but they don't depend on another repo, if that makes any sense.

[AngryLawyer]

I meant more will they stay as seperate, seperately-maintained repos, or are we having everyone hop aboard on this one?

[Cobrand]

What I aimed for was everyone is hoping aboard this repo, but the history of the respectives modules are still kept as git trees, however they are not linked to their repos anymore. Does that make any sense of what I aimed to do ?

It means that if you have changes in ttf, your commit will affect ttf, the main sdl2 crate, but the other trees (image, gfx, ...) won't see this commit. If you commit to sdl2 only, none of the modules will see the commit.

[AngryLawyer]

Yeah I'd be happy with that if that's what everyone else feels is the right thing to do.

[Cobrand]

When I described everything I assumed that the basis was "everyone hop in in this repo" and then the implementation and technical details were kind of up to us

[AngryLawyer]

Ah, I misunderstood and assumed it meant 'everyone keeps seperate repos, but only this one (with logic to automagically merge the other projects into it at the correct time) gets published to crates.io'

[Cobrand]

This kind of solution would be hard to do even if we agreed to do something like this; it would either mean that every contributor to sdl2 would also contribute to every other repos if the change is breaking, meaning 5 PRs instead of 1 (that also means that it's no different from what we have now), or changes are directly made here and 1PR is made, and the respective repos just update from this one, meaning that their repos effectively become useless.

That or there is something I didn't think about and it is actually doable.

So yeah, doing with subtrees would effectively mean abandoning the other crates and repositories as well. I thought that this was what we all agreed about, sorry if I got misunderstood.

[AngryLawyer]

No no, I'm just bad at reading comprehension.

I look forward to seeing what you come up with :)