SDL_sound mirror(s) on Github, or plain git?


#1

Hello all,

Does anyone happen to know if there are any reasonably reliable mirrors of SDL_sound, on either Github, or plain git? I’m looking to link SDL_sound to a Github-hosted project, as a git submodule (for simplified checkout and building). I see plenty of auto-updated mirrors (all non-official, which is fine by me for these purposes) of SDL, SDL_image, SDL_ttf, and the like, but none for SDL_sound.

If not, has anyone here ever set up an automated mirror from hg to git, and might not mind answering a few questions from a hg-to-git newbie? :slight_smile:

Cheers!
– David L.


#2

It looks like you can probably use git-hg as described here. I don’t have any personal experience, but it looks simple enough.


#3

I’ve been thinking of using that, however, if at all possible, I am hoping to go with a plugin-less, pure-git solution. Not for any dislike or disdain of Mercurial, but rather to make it a bit easier for others to clone.

Either way, thanks for the tip!


#4

My main reason for suggesting is because there are no real “blessed” mirrors, in the sense that they could just disappear/stop updating at any time, with or without warning. I’m actually surprised that Ryan and/or Sam don’t host their own git mirror, since then you’d have a lot more guarantees on it, considering the popularity of tools like github.


#5

Yeah… Official git mirrors of SDL would be handy.

In terms of disappearing, it has been on my mind. In some ways, I feel similar regarding external submodules (under any version control system), in general. They can be nice, but it is a risk.

In this case, I ended up bundling copies of SDL_sound, and SDL2, directly into the repo. I’d like it if I could just update things by just altering the submodule reference, but including copies seems ok enough, for now. I suspect it’ll also help a bit with usability, at least from the standpoint of someone attempting to build the app for the first few times.


#6

Maybe some other place than GitHub, they lie in GitHub. They lie, and then become silent, like they have nothing to say. I have good memories about SourceForge, once there were people one could rely on.

Otherwise i would say, the SDL development packages for Windows MinGW are just horrible. I told a friend how to set up MinGW and SDL2 in Windows, and it was terribly difficult to explain it to someone who never compiled anything in C. I think somewhere should be a development package that has all in it, SDL_Image, SDL_ttf, separate packages for 32 and 64 bit, so it would be just bin, lib and include directories under one directory, hopefully named SDL2. One may say that one may like to use different libraries for image, font, sound, etc, but what prevents using a different library even when these libraries are in one package. The library should properly be named SDL2, not SDL, because these are two different libraries, not versions of the same library, this likely though cannot be changed any more. One says CMake now maybe, but CMake has scripts mostly only for one general case, one should be able to make it for any case, the design flaws below cannot really be solved by one more layer of complexity above. My two cents.


#7

Slightly off-topic, perhaps, but I have started work on a patch to allow SDL, in some cases, to be compiled simply by including all of SDL2’s src/ directory. It was meant, in large part, to help with certain, Xcode-based, app project setups, but I wonder if it might help with MinGW, which has often seemed like a troublesome-to-setup-SDL platform for a while now (insofar that a -lot- of help requests seem to come in for it).