SFML 2.1 Visual Studio 2013 binaries + source + template

[Sarbast]

Thank you

[registeredtosaythanks]

You man. Right there.

You are fucking amazing. 

Thank you.

[zsbzsb]

To everyone saying how amazing this.... please just stop and try to learn something instead of going for premade templates that do stuff with MS specific code. There is way more amazing things than a little template that saves maybe 10 minutes of setting up linker options when your actual project will take thousands of times longer.

Learn to compile SFML yourself, its really not hard and takes 15 minutes tops if you stick to the official tutorial. Heck, the install guide for this template is just as long as building SFML. Not to mention learning to compile stuff is part of programming. Oh, and then there is the bugs (some serious ones exist on windows) that exist in 2.1 - not to mention the other great features that have been added since 2.1 in the master branch.

And if you still can't be bother to build SFML yourself........     eXpl0it3r has kindly provided some nightly builds.

[Fitzy]

To everyone saying how amazing this.... please just stop and try to learn something instead of going for premade templates that do stuff with MS specific code. There is way more amazing things than a little template that saves maybe 10 minutes of setting up linker options when your actual project will take thousands of times longer.

Learn to compile SFML yourself, its really not hard and takes 15 minutes tops if you stick to the official tutorial. Heck, the install guide for this template is just as long as building SFML. Not to mention learning to compile stuff is part of programming. Oh, and then there is the bugs (some serious ones exist on windows) that exist in 2.1 - not to mention the other great features that have been added since 2.1 in the master branch.

And if you still can't be bother to build SFML yourself........     eXpl0it3r has kindly provided some nightly builds.

There's really no need for this comment at all, I see where you're coming from but some people have their reasons to go for pre-compiled solutions. The reason I added this in the first place was CMake "was" giving strange error's for Visual Studio 2013 builds.

Helping people just get the stress of figuring out how to compile when all they want to do is just get into it and start testing some code, see if it's something they love or hate. Just chill, leave people to it, if it helps just one then big bonus in my eyes.

[Ixrec]

To me this stuff is a symptom of the fact that C++ as a language is very bad when it comes to the build process.  SFML makes it as easy as it could possibly be, but the fact that we have to manually mess with a dozen IDE settings or find/install a dozen dependencies just to make pre-built binaries work is always going to mean people get confused no matter how clear the official tutorials are.  There's just too many things to screw up, and once you do make a mistake it's basically impossible to figure out which one you made unless you've built that exact same project many times in the past, or come here and ask the people that have (my experience is that most practical build-related knowledge does not transfer to other projects).  Until the C++ modules proposal becomes standard, this isn't really going to improve.

If we want to reduce the need for non-experts to write and use these non-official build methods, I think the only thing we could conceivably do is provide not only the binaries, but complete project folders for Visual Studio and maybe other IDEs so that people can just extract the folder somewhere, open the project file in VS and immediately build and run the examples.  Yes it's better if newbies learn to build everything from source right away, but expecting them to do that for a library they've never used before which has more than zero dependencies is just not reasonable (unless they're on Linux).

[Nexus]

There's really no need for this comment at all, I see where you're coming from but some people have their reasons to go for pre-compiled solutions. [...] Helping people just get the stress of figuring out how to compile when all they want to do is just get into it and start testing some code, see if it's something they love or hate. Just chill, leave people to it, if it helps just one then big bonus in my eyes.

When we always provide half-solutions that ease the process a little bit, but make it impossible to learn things and apply knowlege to other projects, people will encounter the same problems again and again when using different libraries or even different versions of the same library. Furthermore, provided templates are very limited because they have been created for a specific configuration. It may work for people who just want to create a game as quickly as possible, but avoiding the build and link process of C++ is counter-productive and won't help in the long term. People will thank you for the time they save now, not realizing they just postponed the learning effort and will eventually spend even more time on configuration.

To me this stuff is a symptom of the fact that C++ as a language is very bad when it comes to the build process.  SFML makes it as easy as it could possibly be, but the fact that we have to manually mess with a dozen IDE settings or find/install a dozen dependencies just to make pre-built binaries work is always going to mean people get confused no matter how clear the official tutorials are.

What do you mean exactly? Most things you mention are abstracted away by CMake. On Windows even more than on Linux, because third-party dependencies are shipped with SFML. The problem is not that the process is too complicated (even if it arguably is, most of it is done on SFML's side). The problem is rather that a lot of people don't read tutorials carefully. How many threads have been here because people linked the wrong libraries (just mix debug/release or compiler versions), although it is clearly stated in the tutorials? Or how many people do not install SFML but only build it and wonder why the output directory is so ugly?

If we want to reduce the need for non-experts to write and use these non-official build methods, I think the only thing we could conceivably do is provide not only the binaries, but complete project folders for Visual Studio and maybe other IDEs [...]

Providing Visual Studio solutions and Makefiles is even worse because you combine the disadvantages of building from source with those of providing binaries. The former are higher complexity and more possibilities to make mistakes (linking third party libraries, wrong paths, ...), while the latter are decreased flexibility (one has to agree on a specific configuration) and availability only for certain revisions. Additionally, there is more effort needed to provide these templates (especially since the CMake-generated solutions are not really appropriate for shipping), to maintain them and to provide support for them if things don't work.

Yes it's better if newbies learn to build everything from source right away, but expecting them to do that for a library they've never used before which has more than zero dependencies is just not reasonable (unless they're on Linux).

Of course it is -- hundreds of people succeed in doing so. It is especially reasonable, because everything is well-documented and we have a very active community to help at problems. And of course there are still binary distributions.

[Fitzy]

I did say I understood where the comment was coming from, people should learn the build process but it's not always as simple as that, many people come from Managed Languages like Java and C# and want to learn C++ while learning SFML, some just want to learn the basics of C++ before the build process and providing a "TEMPORARY SOLUTION" to achieve that is always welcomed.

As I said, I made this post because CMake had external dependency errors and wouldn't compile properly so for some people who are still learning the C++ build process to only get errors from Cmake which is suppose to make it easier will only frustrate people. It was just a means to an end at the time and is not suppose to be used long term, it was for easy access.

C++ isn't known for it's easy ways of doing things, think like a noob and not like a pro.

[Dada]

For what it's worth (and I'm aware that's close to zero for most of you as this is just opinions from a guy with 2 posts who doesn't even use SFML anymore):

Fitzy and Ixrec are right for the most part and where they are wrong is because they're not going far enough or conceding points in the face of weak arguments.

The ideal SFML user experience can be glimpsed by looking at the Linux installation instructions:
1. sudo apt-get install libsfml-dev
2. done

This is true no matter where the user sits on the noob-to-pro spectrum. While a pro has the *ability* to compile from source and deal with all kinds of issues, they still *prefer* to use a library in packaged form (when it's just a simple dependency on their project). There's many reasons for that, with security and stability sometimes more important than mere convenience (although for a library that isn't hugely popular and arguably targeted at beginners, convenience is the main factor).

This super easy user experience isn't widespread on Windows (yet? I think Nuget has a real shot at bringing this about). In that context, it's perfectly justifiable to say "get the source, install CMake, follow these steps carefully". However that doesn't make the advantages of proper packaging go away, and people who volunteer helpful packaging solutions shouldn't be dismissed as counterproductive.

Not to mention that providing a workaround for an actual issue in the latest official release cannot be a bad thing, surely?

[Ixrec]

I'm not even that bothered by the lack of packaging, though that would also help immensely.  What really annoys me is how unhelpful most C++-related tools are when it comes to figuring out build problems, and how unsympathetic the veterans are after they've learned what each error message actually means.

As a very simple example that would prevent a huge number of the newbie questions we get: Why can't compilers somehow mark their compiled binaries as being compiled by so-and-so version of so-and-so compiler with or without debug mode, then complain when they're asked to link against something that doesn't match?

In fact, where I work, the infrastructure people have effectively taught our compilers to do just this by adding some version macros into all their libraries, making it impossible for us to build against the wrong version of anything by accident.  Is there any reason SFML can't do something like this?

[Laurent]

The problem is that there are potentially a huge number of compiler or linker settings that can make two binaries incompatible. You can reduce it to a few in a known and controlled environment (like where you work), but I don't know if it would be possible to make something generic.

[MorleyDev]

For my university project I actually looked at C++ dependency management. I concluded pretty early on that any kind of binary hosting-based dependency management system is impractical at best, impossible at worst. So I made a system that uses Git and CMake to acquire, compile and cache dependencies, then updates those compiled dependencies. So long as the compiler in use for MinGW/Unix Makefiles remains consistent, ease of install and binary compatibility are fixed. Though you update/change compilers, you do have to manually delete the cache atm.

So using this system, getting the latest SFML debug binaries is as simple as:
zander_client get sfml2 mingw debug

Which will, internally do a git clone or git pull of sfml to a source cache, then do a cmake build of sfml2, install the artefacts from that build into an artefact cache, and then copy those artefacts to the working directory. If artefacts are already in the cache and up-to-date, it just does the copy to the working directory. If they're in the working directory but out of date, they get replaced by the up-to-date artefacts. If they're in the working directory and up-to-date, nothing happens.

At the moment the tools are pretty simple, a client written in scala and a simple rest api written in node.js, but I was planning on posting them here after I add a few more features. Like support for tags and branches, and custom cmake flags (which means different branches, tags and flags will have to result in a different cached artefacts).

Also it requires the source to be open source, hosted in a git repository and buildable and installable via cmake. So baby steps xD

[Durranos]

I don't care if I'm necroing this thread. I made an account just so I could post that this was a life saver. I've been screwing around trying to get SFML to cooperate with VS 2013 for a week now. I stumbled onto your solution and omg thank you so very much. It worked like a charm the first time around. Your instructions were clear, precise and very well documented. I tip my hat to you sir, thank you so much!

[StormWingDelta]

As good as this is it needs a few more templates.  One for Console, One for Forms, and one for each of those on the C# version.


Yes this makes people lazier but what's funny is some of my classmates found out that we programmers are here to make things easier for others to do even if it does make them lazier in the end.

[renodubois]

Worked like a charm, thanks for this!