SFML source and Visual Studio 2013

[yoni0505]

Today I tried to compile SFML for Visual Studio 2013 Express RC.
Using CMake-GUI, I configured to make static libs (BUILD_SHARED_LIBS unchecked), and some of the projects failed to load.

The problem was that some of the .vcxproj files had unnecessary &quot";" next to some of the quotes inside tags.
So to fix it you simply have to remove all the &quot";" from these files.

I'm unfamiliar with the cmake stuff, so is it a bug with CMake-GUI, Visual Studio 2013, or the implementation of SFML's cmake?

Oh and if anyone is interested, here's the VS 2013 RC build I compiled:
http://www.mediafire.com/?49879nw207yv0ac

[eXpl0it3r]

Shouldn't have anything to do with SFML, since the build script is using CMake language to describe what CMake itself should generate. Then again you're using an RC = Release Candidate = Not Officially Released = Might Have Bugs version of Visual Studio, so you shouldn't be surprised if you run into any issues.
I'm sure once VS12 is officially out, CMake will bring out an update, which will be fully compatible. In the mean time, you might want to generate NMake files instead.

[MorleyDev]

To be honest, the CMake GUI sucks. Always has. It's much easier to just use the command line.

Also to build SFML for Visual Studio 2013 RC at the moment, I have found I have to explicitly tell msbuild to change a flag to the correct visual studio version. The following works for me when ran by the command line: EDIT: Nevermind, last cmake update added Visual Studio 12 support. I've modified the scripts to reflect.

Code: [Select]

cmake <PATH TO SFML> -G"Visual Studio 11"
"C:\Program Files (x86)\MSBuild\12.0\Bin\MSBuild.exe" /p:Configuration=Release SFML.sln

Obviously replacing <PATH TO SFML> with the path to the root of the SFML directory. Also the location of the VS12 (Visual Studio 2013) msbuild on your system may be different.

EDIT: Here's a batch script (save it as a .bat and run from the command line) to completely download and rebuild SFML, and extract the headers, libs and bin into appropriate folders for both debug and release.

Code: [Select]

mkdir sfml2
pushd sfml2
mkdir include
mkdir lib
mkdir bin

git clone https://github.com/SFML/SFML.git
pushd SFML
mkdir build
pushd build
cmake .. -G"Visual Studio 12"
"C:\Program Files (x86)\MSBuild\12.0\Bin\MSBuild.exe" /m:10 /p:Configuration=Debug SFML.sln
"C:\Program Files (x86)\MSBuild\12.0\Bin\MSBuild.exe" /m:10 /p:Configuration=Release SFML.sln

xcopy lib\Debug\*.lib ..\..\lib /Y /S /I
xcopy lib\Debug\*.dll ..\..\bin /Y /S /I

xcopy lib\Release\*.lib ..\..\lib /Y /S /I
xcopy lib\Release\*.dll ..\..\bin /Y /S /I
popd
xcopy include ..\include /Y /S /I
popd
rd SFML /S /Q
popd


[eXpl0it3r]

No wonder CMake doesn't find the right version if specify the wrong one. It should be cmake -G"Visual Studio 12" not 11 (VS 11 = VS 2012, VS12 = VS 2013). Also you always have to specify which generator to use, plus the GUI is not bad at all, it's basically just listing all your variables, thus it's easier to play around with since you don't have to retype everything and you can easily switch between normal and advanced settings.

[The Illusionist Mirage]

To be honest, the CMake GUI sucks. Always has. It's much easier to just use the command line.   

Up to some extent,  I agree with you that the command line is better than GUI. Since I am quite new to CMake myself, whenever a build fails in the command line, I have to revert to the GUI.

[MorleyDev]

Huh, I'm sure when I looked at the list of generators for 2.8.11 it still didn't list Visual Studio 12...my mistake. I've amended my original post, and modified the scripts I posted to reflect.

CMake gui gives me more issues than command line ever does over the little things like "MinGW Makefiles" needing CMAKE_MAKE_PROGRAM defined.

I still stand by it's better to use the cmake command line, but I can be a bit obsessed with automation at times. Why do yourself what the computer can be scripted to do for you in two lines? I always script my 3rd party installs nowadays, much easier than faffing around with manual copying and manual building.

[eXpl0it3r]

Tbh I was surprised as well that VS 12 was in.

Yeah I also use scripts (e.g. for my Nigthly Builds), thus it's a must there, but whenever I get a new library, I rather go with the GUI, because I don't know what variables the CMake script generates for me, and hsving to type all these lengthy name (CMAKE_MODULE_PATH, CMAKE_BUILD_SHARED, etc etc), is just rather painful, especially since CMake generates these names for me with GUI. Or mind you add a space between -D and your variable, good luck figuering out the error.
Of course you can keep your opinion, not trying to convince you, just showing the benefits I see.

[FRex]

What about cmake -i?

[Mario]

CMake gui gives me more issues than command line ever does over the little things like "MinGW Makefiles" needing CMAKE_MAKE_PROGRAM defined.

• Open a command prompt with admin rights.
• Go to MinGW's bin dir.
• Run "mklink /D make.exe mingw32-make.exe"
• Profit. :)

[gbromios]

I know it was meant to be a simple example of how to make for vs2013, but this explanation is actually the nicest, cleanest tutorial for building libs on Windows I've ever seen. This is a process which before was completely opaque and baffling to me as someone who has only ever really programmed in Linux. Thanks!!