SFML community forums
General => General discussions => Topic started by: Laurent on June 04, 2010, 09:19:34 pm
-
Hi
I'd like to know your opinion about using CMake as the build system for SFML. I've hesitated for a long time, but it would really make things much easier for me.
Here is a list of cool things about CMake:
- I can make a new release (compiling + packaging for all compilers) in one click, thus I'd be able to release more versions, more often
- No more unsupported compilers/IDEs (like VC++ 2010, MinGW makefiles, Eclipse project files, Borland workspaces, ..)
- No more troubles with the supported compilers/IDEs
- Users can customize their own build options (compile only some modules, disable samples, ...)
- Dependencies auto-detected, and you get a clear error message at configure-time if one of them is missing
The main drawback, of course, is that all the users that regularly compile SFML from sources will have to install CMake and use it :)
For those compiling with an IDE, the generated projects are not very "attractive" and look very messy, but in my opinion when you build with CMake you don't need to use the IDE anymore.
So what do you think ?
-
If it will make it easier to compiler in VC++ 2010, by all means go for it :D
I can't imagine that it's that much effort to install + use cmake: it even seems to have a gui on windows!
-
I can't imagine that it's that much effort to install + use cmake: it even seems to have a gui on windows!
Yes it does.
Plus, you only need to go through the configuration step once: if the config changes, CMake will automatically be invoked to update the build files the next time you compile.
-
I've been using CMake for my projects for over a year now, and I heartily recommend it. It is by far the least painful, most cross-platform build system I've ever used.
If you're switching to CMake, does that mean you're going to provide a FindSFML.cmake module for people developing SFML-based projects with CMake to use?
-
If you're switching to CMake, does that mean you're going to provide a FindSFML.cmake module for people developing SFML-based projects with CMake to use?
It already exists ;)
http://www.sfml-dev.org/forum/viewtopic.php?p=15753#15753
-
If you're switching to CMake, does that mean you're going to provide a FindSFML.cmake module for people developing SFML-based projects with CMake to use?
It already exists ;)
http://www.sfml-dev.org/forum/viewtopic.php?p=15753#15753
Ah, that it does. I'm actually using that one now, I just didn't know if you had plans to create an "official" one. I suppose there isn't much need, though.
-
Go with cmake, especially if it would make life easier for you. 8) I too use cmake for personal projects. cmake is most sane build system there is.
-
CMake gives me a more common interface (apart from make ; make install sfml is -- well a bit custom) ;)
-
If its easier for you, I say go for it! I know what its like to work in a development environment you're not too happy with. Makes you just not want to write anything.
-
+1 vote for cmake :) It sounds far too great to miss it :D
-
*sign*
-
Hi,
I have sadly seen many libraries for game development that were not updated for Visual C++ 2010 and that the automatic converter did not work on. However, with CMake, I have been able to update these older libraries for my compiler with no problems at all!
SFML, unfortunately, has the inability to work with Visual C++ 2010 Properly even though the converter does work on it. I genuinely believe CMake support could fix this problem. I hope to see it in the next edition of SFML.
-
Oh dear yes, please switch to CMake! I wondered why you still bothered with all those manual project files. I offer my help in setting up the project with CMake if you get stuck.
-
Any progress on this? SVN doesn't appear to have any changes related to this.
-
Any progress on this?
Yes, I'm still working on it.
SVN doesn't appear to have any changes related to this.
It won't until it is completely done ;)
-
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.)
-
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?
-
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.
-
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?
-
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.
-
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?
-
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.
-
If something new is integrated directly into SFML, I must be able to maintain it.
-
YES
:P
-
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)