Switching to CMake

[Skrylar]

I just did a full checkout of the 2.0, trunk and 1.6 tag; I'm going to see if I can whip up a quick set of CMake files that will at least get SFML built enough to be usable since I don't see any in the repository for 2.0;

My ultimate goal is to see if I can splice the also-BSD code for handling sound files from Allegro 5 and drop sndfile as a dependency for SFML; it would be nice to have a purely BSD environment to work with (as it is now if you use SFML for all things, you get stuck in the face with LGPL requirements.)

[Laurent]

I just did a full checkout of the 2.0, trunk and 1.6 tag; I'm going to see if I can whip up a quick set of CMake files that will at least get SFML built enough to be usable since I don't see any in the repository for 2.0;

It's work in progress (and almost finished), so don't bother writing CMake files again from scratch.
If you want I can send you the current version of my CMake files, they should work at least for dynamic build.

My ultimate goal is to see if I can splice the also-BSD code for handling sound files from Allegro 5 and drop sndfile as a dependency for SFML; it would be nice to have a purely BSD environment to work with (as it is now if you use SFML for all things, you get stuck in the face with LGPL requirements.)

That would be great.
Which sound formats does this code support? It is robust enough, or at least actively maintained?

[Skrylar]

It's work in progress (and almost finished), so don't bother writing CMake files again from scratch.
If you want I can send you the current version of my CMake files, they should work at least for dynamic build.

Mkay. I had part of a set built already but it looks like the current SVN for 2.0 doesn't run on a Mac due to lacking the code for AGL contexts so I moved the work over to work for 1.6/1.7; if you don't have scripts for those I can put up a patch file (they were really trivial to make.)

That would be great.
Which sound formats does this code support? It is robust enough, or at least actively maintained?

From the docs:

Depending on what libraries are available, the full set of recognised extensions is: .wav, .flac, .ogg, .it, .mod, .s3m, .xm.

It's not as many as sndfile lists but it covers the most common ones that most games actually need. As for maintenance, Allegro 5 seems to be in healthy development.

[Laurent]

if you don't have scripts for those I can put up a patch file (they were really trivial to make.)

Well, the development of the SFML 1.x branch is officially stopped (except for bug fixes), so I'm never going to change the build system here.

Depending on what libraries are available

What does that mean? If it relies on other external shared libraries, I don't see any reason to replace libsndfile with it.

it covers the most common ones that most games actually need

Yep, this is fine for me. Too bad there's no MIDI or MP3 (maybe for the same reasons as me).

As for maintenance, Allegro 5 seems to be in healthy development.

Won't it be tedious to synchronize your own clone everytime there's an update?

[Skrylar]

Depending on what libraries are available

Same external libraries as sndfile; it uses libogg and libvorbis to do the vorbis decoding (which can be bundled in like the image libs are) and libDUMB for modules (which is also BSD and can be bundled.)

Won't it be tedious to synchronize your own clone everytime there's an update?

Yes and no; the audio code is a minuscule portion of the entire library and I know of no bugs with it that need fixing. It's also kept as two separate modules (one for sound, the other for ogg/xm) so the code separation is clean.

[Laurent]

Same external libraries as sndfile; it uses libogg and libvorbis to do the vorbis decoding (which can be bundled in like the image libs are) and libDUMB for modules (which is also BSD and can be bundled.)

Ok, so on Windows they must be statically linked in order to keep only one dependency for the whole thing. I think there's no problem with that.

Yes and no; the audio code is a minuscule portion of the entire library and I know of no bugs with it that need fixing. It's also kept as two separate modules (one for sound, the other for ogg/xm) so the code separation is clean.

Ok.

I have another question: will this thing be part of SFML, or do you want to make it a new library?

[Skrylar]

Depends on if it actually ends up working in the end and how complicated it is. I had been thinking to patch the Allegro code in to SFML if I could fit it in to the existing API well enough.

[Laurent]

If something new is integrated directly into SFML, I must be able to maintain it.

[Hugo]

YES
 

[MarthKoopa]

The benefits of CMake you listed there are pretty great, I say go for it, especially if it makes things easier for you. (bad pun alert)