SFML community forums
General => General discussions => Topic started by: Laurent on August 19, 2010, 06:04:14 pm
-
Hi
My huge commit from today adds support for the CMake build system, as well as renaming some parts of the repository tree.
Things to know:
- I haven't written CMake files for CSFML yet, this is my next task
- there's no tutorial yet, this is my second next task
- the old project files and makefiles are still maintained, but at some point before the public release they will be removed; so you'd better switch to CMake as soon as you can
- although I've spent a rather big amount of time on the CMake makefiles, there are probably mistakes and things to improve, so don't hesitate to give your feedback
-
So you will not provide project files in the next release? :(
-
No, it is no longer necessary. If you want to recompile SFML you can generate the project files for your favorite IDE/compiler with CMake.
-
Another tool necessary to use SFML. That will increase the number of problems if you just want to recompile SFML.
You are now able to create project files easily. Please do that for the IDEs and platforms which are used most. :)
-
I figured out how to do this, I think, but I don't see any DLLs or Libs anywhere.
I have "where is the source code" set to C:\SFML-2.0\
and "where to build the binaries" set to C:\SFML-2.0\lib\
This is the output I got for VS9 2008 on the first configure click:
Check for working C compiler using: Visual Studio 9 2008
Check for working C compiler using: Visual Studio 9 2008 -- works
Detecting C compiler ABI info
Detecting C compiler ABI info - done
Check for working CXX compiler using: Visual Studio 9 2008
Check for working CXX compiler using: Visual Studio 9 2008 -- works
Detecting CXX compiler ABI info
Detecting CXX compiler ABI info - done
Looking for sys/types.h
Looking for sys/types.h - found
Looking for stdint.h
Looking for stdint.h - not found
Looking for stddef.h
Looking for stddef.h - found
Check size of void*
Check size of void* - done
Entering C:/SFML-2.0/src/SFML
Entering C:/SFML-2.0/src/SFML/System
Returning to C:/SFML-2.0/src/SFML
Entering C:/SFML-2.0/src/SFML/Window
Returning to C:/SFML-2.0/src/SFML
Entering C:/SFML-2.0/src/SFML/Network
Returning to C:/SFML-2.0/src/SFML
Entering C:/SFML-2.0/src/SFML/Graphics
Found Freetype: C:/SFML-2.0/extlibs/libs-msvc/freetype.lib
Found JPEG: C:/SFML-2.0/extlibs/libs-msvc/jpeg.lib
Returning to C:/SFML-2.0/src/SFML
Entering C:/SFML-2.0/src/SFML/Audio
Found OpenAL: C:/SFML-2.0/extlibs/libs-msvc/OpenAL32.lib
Found SNDFILE: C:/SFML-2.0/extlibs/headers
Returning to C:/SFML-2.0/src/SFML
Entering C:/SFML-2.0/src/SFML/Main
Returning to C:/SFML-2.0/src/SFML
Returning to C:/SFML-2.0
Configuring done
I clicked it again, because generate wasn't clickable, then generate became clickable and I got this:
Entering C:/SFML-2.0/src/SFML
Entering C:/SFML-2.0/src/SFML/System
Returning to C:/SFML-2.0/src/SFML
Entering C:/SFML-2.0/src/SFML/Window
Returning to C:/SFML-2.0/src/SFML
Entering C:/SFML-2.0/src/SFML/Network
Returning to C:/SFML-2.0/src/SFML
Entering C:/SFML-2.0/src/SFML/Graphics
Returning to C:/SFML-2.0/src/SFML
Entering C:/SFML-2.0/src/SFML/Audio
Returning to C:/SFML-2.0/src/SFML
Entering C:/SFML-2.0/src/SFML/Main
Returning to C:/SFML-2.0/src/SFML
Returning to C:/SFML-2.0
Configuring done
Generating done
-
Another tool necessary to use SFML. That will increase the number of problems if you just want to recompile SFML
Once the projects are generated, you don't have to care about CMake anymore, just run the generated makefiles/projects (they will even update themselves automatically if the CMake configuration has changed).
Please, at least try it before arguing, you'll see how simple and powerful it is ;)
And this is actually reducing the number of problems, maintaining a single generic build configuration for every platform/compiler rather than a different one for each of those, is much less error prone. And it gives access to previously unsupported compilers/platforms, for free.
By the way, I asked the community about a month ago about this modification, now it's too late to be against it.
I figured out how to do this, I think, but I don't see any DLLs or Libs anywhere.
You just configured the project, ie. you created the makefiles/projects. Now you have to use them to actually build SFML.
Please read CMake tutorials, if you really want to use it before I write my own tutorial for compiling SFML.
-
Another tool necessary to use SFML. That will increase the number of problems if you just want to recompile SFML
Once the projects are generated, you don't have to care about CMake anymore, just run the generated makefiles/projects (they will even update themselves automatically if the CMake configuration has changed).
Please, at least try it before arguing, you'll see how simple and powerful it is ;)
And this is actually reducing the number of problems, maintaining a single generic build configuration for every platform/compiler rather than a different one for each of those, is much less error prone. And it gives access to previously unsupported compilers/platforms, for free.
By the way, I asked the community about a month ago about this modification, now it's too late to be against it.
I am not against CMake. You have now the ability (using CMake) to create the project files even more easily than before so I see no reason why to drop it (Maybe, to reduce the effort you can drop the support for very old IDEs (vc2005) ;) ).
Another point is, that it becomes more difficult to explain other people how to compile SFML if they have to do more steps than before. Its another Step where problems appear.
I am also not talking about putting those project files into the repo any more (because refreshing those project files every commit is painful) but just giving project files each release.
So, please neither drop the support for the project files (which can be generated easily now) nor the support for CMake (I never asked for that, and I know, that its usefull to maintain a project for different platforms.)
-
The problem is that project files generated by CMake are pretty ugly... not really ready to be distributed.
In fact there's no point generating/distributing them anymore, except for me and other SFML developers. To simply compile SFML, makefiles are always much better.
-
I think Mr. X is right. Sure, the generated project files are ugly (computers never had a sense of beauty, right? ;)), but better ugly project files for a release than none.
This of course only applies for full binary releases. For everything else, everybody should be able to read the fine manual and get things working.
However, it's great that you switched to CMake, good work.
-
I don't think it's complicated, even for a beginner, to understand how to generate them.
Here are the reasons why I don't want to distribute the final projects/makefiles:
1. The projects/makefiles are ugly, but there are also a full hierarchy of CMake specific files that come with them ; it becomes really ugly to distribute, and unnecessary.
2. CMake generates a cache of the paths that it detects, and these paths are absolute; so if I distribute my generated projects/makefiles, it's simply not going to work.
3. There are so many ways to generate build files for a given compiler with CMake, I can't distribute one that makes everybody happy. For example, to build with Visual Studio I can generate VC++ projects or nmake makefiles. Some people will prefer the former, and some others will prefer the latter. The build tree can be generated inside the source tree, or outside. Again, some will like and some won't. You can also setup the install path when you create makefiles/projects, for the "install" rule. You can also choose or not to compile the doc, the examples, etc...
So I prefer to leave users with the huge flexibility of CMake, and customize their SFML build the way they like, with the cost of executing a small command to generate the build files.
-
From a first look at the lists it looks like a good job and clean work. I have yet to try it out. Thanks for your work, Laurent.
CMake will finally allow me to cross-compile properly.
There will always be naysayers but they might not be experienced enough to judge the situation in its entirety. CMake is currently the only sane choice for cross-platform applications and libraries unless you want to do all the maintenance yourself which is error prone anyway.
-
will always be naysayers but they might not be experienced enough to judge the situation in its entirety. CMake is currently the only sane choice for cross-platform applications and libraries unless you want to do all the maintenance yours
elf which is error prone anyway.
This has nothing to do with being a "naysayer", it's called a discussion where everybody who may concern can take part with his own personal opinion. And guess what, sometimes these discussions can lead to new and maybe better solutions.
Nobody says "You are doing it wrong", but instead "I think maybe this or that could be an improvement". You have the same opinion like the maintainer, so you are happy, but don't call other people unexperienced because they have another one. Indeed CMake is not the only tool to keep good cross-platform capabilities for the build system.
And, to get a bit more personal (yep, I feel being pissed at): Don't mix this or any other discussion with personal stuff regarding to me or Mr.X. PM me in case of interest.
-
CMake does sound pretty sweet. But I get what Mr. X and Tank are saying about maintaining pre-made projects for n00bies like me. But honestly that can wait until the release of v2.0 IMHO. It sounds like cmake relieves Laurent of the responsibility of maintaining different project and make file setups for different projects so he can focus on actually making improvements on SFML.
There is no reason to get annoyed at each other over this. :roll: The switch to cmake is very young and Laurent hasn't even made a tutorial yet. Nothing is stopping Laurent or someone else from making cleaner projects in the future.
-
The switch to CMake was a very good decision in my eyes, I have nothing to complain about. :) Indeed using CMake is easy, and with a little step-by-step guide everybody should be able to generate project files. However, I still think providing at least project files for the latest and most popular IDEs wouldn't be wrong (not for all possible configurations, versions, platforms etc.).
There is no reason to get annoyed at each other over this.
This has actually nothing to do with CMake in the first place. I'm sorry that I brought this to a public table.
-
However, I still think providing at least project files for the latest and most popular IDEs wouldn't be wrong
Technically, I think the following reasons make it unfeasible
1. The projects/makefiles are ugly, but there are also a full hierarchy of CMake specific files that come with them ; it becomes really ugly to distribute, and unnecessary.
2. CMake generates a cache of the paths that it detects, and these paths are absolute; so if I distribute my generated projects/makefiles, it's simply not going to work.
In fact I don't think that CMake generated files are made for being distributed.
-
This has actually nothing to do with CMake in the first place. I'm sorry that I brought this to a public table.
I do not think that you brought this to a public table...
But you are right, that discussion has nothing to do with CMake.
-
was just, curious, when CMake generates a vs2010 project file, the build options are, Release, Debug, MinSizeRel, and RelWithDebInfo,
does any of these produce static version of the lib?
-
To get a static version of the libraries, you must set BUILD_SHARED_LIBS to FALSE.
-
I'd prefer an option to build both a static and a dynamic library at the same time.
See here: http://www.itk.org/Wiki/CMake_FAQ#Can_I_build_both_shared_and_static_libraries_with_one_ADD_LIBRARY_command.3F
EDIT: So basically I want BUILD_STATIC as an optional flag for building static libs.
-
I'd prefer an option to build both a static and a dynamic library at the same time.
Why? Are you really using both?
And you don't need to have an option in the CMake files, you can simply generate both configurations separately and compile them together when you want both versions.
-
I'll typically use dynamic SFML but for Windows deployment I prefer cross-compiling and linking static instead of shared. Also, since I'm packaging SFML for Arch, it would be neat if I would have to do less manual work to provide my users with both versions.
-
Don't forget that once you generate the makefiles, you never have to do this step again. So the "manual work" of generating another version of the libraries is almost free.
This is one of the cool things with CMake: people can really customize all the configurations they want, and they only have to do it once.
-
To get a static version of the libraries, you must set BUILD_SHARED_LIBS to FALSE.
Worked great, thanks!
-
So, uh, how exactly do you use the CMake system? I tried cmake -P CMakeLists.txt at the top of the sfml2 directory, but it gave some error about project() on line 11.
-
Running "cmake" is enoughIt's often better to run it from a different directory, so that the source tree is not polluted wit hteh build files.
Anyway, what error do you get?
-
Running "cmake" is enoughIt's often better to run it from a different directory, so that the source tree is not polluted wit hteh build files.
Anyway, what error do you get?
Running just "cmake" gives me the usage info.
It gives me this: "Command project() is not scriptable".
-
Just use cmake -i : it runs in "wizard" mode and asks for everything.
-
Just use cmake -i : it runs in "wizard" mode and asks for everything.
That works so much better. Thanks!
-
hey, Im trying to build a static SFML2 version made with cmake (again) but this time on visual studios 9 (instead of 10), however when i do so i get 2 errors,
Error 1 fatal error LNK1107: invalid or corrupt file: cannot read at 0xA5 C:\Documents 1 sfml-audio
Error 2 fatal error LNK1107: invalid or corrupt file: cannot read at 0xA5 C:\Documents 1 sfml-graphics
I could swear I've seen this before but cant quite remember, (google search/forum search doesn't help either)
any idea as to what's going on when trying to build the static libs?
(when i use CMAKE to generate the shared library, it builds successfully)
much appreciated
-
Maybe it doesn't like the spaces in your path.
I'll see if I can do something about it, but avoid spaces anyway, they are evil.
-
Maybe it doesn't like the spaces in your path.
I'll see if I can do something about it, but avoid spaces anyway, they are evil.
I figured it was something like that, since it cuts off at C:\Documents,
either way i found vs 9 project files in the build folder, (not sure how i didn't notice this earlier) either way, I was able to compile the library using it!
-
Yep, but they are now deprecated and will be removed before the official release, so you should get used to CMake anyway ;)
-
I've improved the CMake files, so that paths with spaces should be ok now in Visual Studio.
-
Can you explain your FindSFML.cmake file? I mean, how do we specify which SFML libraries to use?
-
Do it like this: http://github.com/svenstaro/NoisyHunter/blob/master/CMakeLists.txt
Then link like this:
http://github.com/svenstaro/NoisyHunter/blob/master/engine/CMakeLists.txt
-
Do it like this: http://github.com/svenstaro/NoisyHunter/blob/master/CMakeLists.txt
Then link like this:
http://github.com/svenstaro/NoisyHunter/blob/master/engine/CMakeLists.txt
Alright, thanks!
-
set(SFML_FIND_VERSION_MAJOR 2)
find_package(SFML COMPONENTS audio graphics network system window REQUIRED)
Do this instead
find_package(SFML 2 COMPONENTS audio graphics network system window REQUIRED)
-
Oh that is neat, will change my line to look like that. Thanks Laurent.
-
just a note after reading through the thread.
I'm a complete beginner and the CMake files worked right off the bat the first time. I just ran build all and it figured out the rest.
If I can do it, anyone should be able to do it :)
-
just a note after reading through the thread.
I'm a complete beginner and the CMake files worked right off the bat the first time. I just ran build all and it figured out the rest.
If I can do it, anyone should be able to do it :)
I think that the bat file has nothing to do with CMake.
-
well that would be the complete beginner in me misunderstanding the thread :(
Anyways my point is that I had no problem getting it set up and running.
-
If you used the batch builds, it's normal because there's nothing to setup, just running them is enough ;)
With CMake you have to run a specific tool, configure the build options, then launch the compilation manually.
-
Ah ok. I'll have to read up on CMake
Thanks for explaining that :)