Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

SDL_ttf support. #71

Open
dpc opened this issue Jul 3, 2013 · 8 comments
Open

SDL_ttf support. #71

dpc opened this issue Jul 3, 2013 · 8 comments

Comments

@dpc
Copy link
Contributor

dpc commented Jul 3, 2013

My game (rustyhex) needs some text. ;)

Will do this myself in some future (once I find some time) if no one else is going to do it faster.

@rossmurray
Copy link
Contributor

Should this go into rust-sdl or be a separate library? I'm wondering the same thing for SDL_gfx or SDL_Draw. I started on a separate library for gfx because I didn't know what would be best.

@sfackler
Copy link
Contributor

sfackler commented Jul 7, 2013

I'm thinking all of the SDL_* libraries should be separate, including SDL_image and SDL_mixer. If they live inside of this project, then people packaging rust-sdl up for e.g. Ubuntu have to decide if they're going to require everyone to install SDL_image or not support it at all.

I'm working on SDL_ttf bindings here: https://github.com/sfackler/rust-sdl_ttf. It's in the very early stages, but it should be fleshed out relatively quickly.

@AngryLawyer
Copy link
Collaborator

Yeah, I'd prefer them to be in external libs, to be honest, but that's just personal taste. SDL_image and SDL_mixer should probably be moved out at some point.

@itdaniher
Copy link
Contributor

+1 for moving out, but at that point, it might make sense to build a metarepo that includes the subprojects as git submodules and includes working build scripts for ease of test / use.

@brson
Copy link
Owner

brson commented Jul 26, 2013

FWIW I have no opinion here, but it sounds like consensus is leaning toward keeping these libs separate. It may be worth talking to @catamorphism to find out if we can have a single git repo that contains multiple rust libraries, leaving them all here, but as different libs. That would possibly be easiest to manage since in my experience git submodules are more-or-less a nightmare. Alternately, if those with a stake want to agree on some multi-repo structure I'm happy to deprecate this one and let development move elsewhere.

@sfackler
Copy link
Contributor

IIRC, submodules are no longer forced to track a specific commit and can now track a branch or tag which should make them much more usable. I haven't tried out the new functionality yet, so I don't know if it's still awful.

@AngryLawyer
Copy link
Collaborator

If we stick everything in one repo, how will Rustpkg deal with that?

@brson
Copy link
Owner

brson commented Jul 29, 2013

@AngryLawyer I don't know off hand but @catamorphism would. At one point at least supporting multiple crates in a single repo was a proposed feature.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants