How do you like to handle Multiplatform SFML projects?

[Gan]

I've been using SFML for my project in Xcode and it was beautiful so I decided to port it to windows with Code::Blocks. Few road bumps but it now works fairly flawlessly.
Of course now I have 2 different versions on different OSes in different IDEs. I'd like to keep Xcode on my Mac for the semantic highlighting (which is quite amazing) which Code::Blocks sadly lacks.
Of course I can just copy my changed source files, move them with a flash drive and replace old files but that's a tad tedious.
I'm thinking of setting up a repository to keep source files the same for my stationary PC and for when I'm out in the world programming on my Mac laptop. (Granted Code::Blocks can handle repositories)

How would you handle this situation, or if you have, how did you manage?

[eXpl0it3r]

I'd use CMake as my project file generator, thus it would be easy to generate a new project file for whatever IDE/build system I wanted to use.

Usually there are two ways towards developing on multiple platforms:

• You're actually developing the game on different OS and switch whenever you want.
• You develop on one OS with one development environment and whenever you've finished your sprint or similar, you switch to the other OS and integrate it there.

The first method is somewhat harder as you've already experienced and one can lose quite a bit of time keeping everything constantly up-to-date on both OS.

The second method is afaik more common and it's also what I've used in the past, but (!) it only works if you write portable code, otherwise you'll spend days getting things working again on the other system. Getting things to compile on both systems, once you've got a larger dependency list is already quite time consuming.

In any case, I'd say you most definitely should setup a repository. Personally I prefer Git as it very powerful and lets you choose from different work-flows, instead of forcing one onto you.

On the one bigger project I'm involved with, we got the main developer, who's developing everything on Debian and has setup various Git repositories for all the internal libraries. Whenever I want to work on the project I can simply go, checkout the repositories and either work on the code directly (e.g. with Vim) or let me generate a IDE file (e.g. Code::Blocks) and off I go. Once I've made my changes, I commit them to a separated branch and push them back to the repository, where then main dev then gets to review my changes and merge them back into the project. Of course when you're the only dev you could potentially commit to the working branch directly.

I hope my wall of text made any sense...

[Gan]

That sounds really interesting. I've used Git to download source files, and cmake to generate project files but I've never used them to manage a repository or generate files for my own project.
I guess this'll take some research!

I've heard that DropBox is a really easy way to synchronize the source on whatever machine you choose to be at. Seems pretty brilliant whoever originally thought of it. I might try that out first.

[Sui]

I'm in the process of setting up a new development environment for multi-platform development. Initially this will be Windows/Mac OSX. At some point I'll set up Linux (Ubuntu) on a VM and built on there as well.

I have opted for Mercurial rather than git. They are pretty similar conceptually, being distributed rather than centralised. Due to coming from a Microsoft development background, I have used SourceSafe in the past which is horrible and clunky. The bindings always seem to cause grief. Mercurial is much simpler in design, in that the change tracking repository just lives in a folder with the source. So far, I really like it.

I opted for Mercurial because the tools seem to be more complete under Windows. The git GUI tools seem to be in beta. A lot of people just use command line, therefore this isn't a problem. I spent a lot of time using command line tools in DOS/VAX/Unix environments in the past but these days I'm old and lazy and prefer whizzy tools. The graphical diff and history diagrams are nice in the Mercurial tools.

Discussion about source control tools seems to often ignite a debate of almost religious proportions... each to their own I say.

In order to have a central code repository and share media I bought a Synology NAS. This is also very useful for sharing documents, photos etc. and allows testing of PHP/mySQL applications offline. I blogged a bit about the Synology box:

http://suisoftgames.blogspot.co.uk/2012/12/nas-box-setup.html
http://suisoftgames.blogspot.co.uk/2012/12/synology-part-ii.html

My next job today is setting up the Mercurial tools on Mac OSX.

I'll be posting a blog about Mercurial at some point. I'll try to remember to bob it on here.

[firefly2442]

+1 for Git and CMake.

Mercurial is nice too but I don't have as much experience.  Ensuring your code is in some kind of version control means you can test things and break your code trying something without having to worry about making backups or messing up your existing codebase.  That's really handy.  Plus the fact that you can easily back it up somewhere.  You don't want to do all this work coding and then have your computer crash and lose everything.

Dropbox is also nice but I wouldn't recommend it for sourcecode.  I think Dropbox is much better suited to saving documents and pictures.  Sourcecode changes too often and while they do have the ability to download previous versions of the file, you have to do it through their web interface which is kind of a pain.

[MorleyDev]

I've lately discovered I much prefer qmake to cmake...in that I can get qmake to work... plus Qt Creator works very well as an ide it turns out. Lucky for me, since eclipse decided it no longer wants to play nice with the latest version of GCC on windows.

Not sure why but cmake just hates me. Can't get it to play nice at all, especially when I have Git's sh.exe and associate tools on the path...funnily enough some of my other tools, like eclipse, don't play nice when sh etc aren't on the path...

[Ancurio]

I've lately discovered I much prefer qmake to cmake...in that I can get qmake to work... plus Qt Creator works very well as an ide it turns out. Lucky for me, since eclipse decided it no longer wants to play nice with the latest version of GCC on windows.

Cool^^ I use qmake+QtCreator for my SFML work too, but that's mostly because almost all of my limited C++ experience so far has been in relation to Qt (work related, didn't use C++ before). I really love Creator and feel very comfy in it, so just using qmake and simply "coding away" was a no brainer. I might switch to something else later though if it limits me in any way (e.g. cross platform deployment).
I tried to get into cmake once, but it seemed very complicated.. I could never wrap my head around either cmake or autoconf for that matter..

[Nexus]

CMake is indeed not very user-friendly. It is quite powerful if you know what to do, but one can quickly lose the overview. Also, as soon as you do something which is not very basic, you have to write a lot of code and re-invent the wheel again and again. The worst thing in my opinion is however, that although CMake intends to abstract from multiple build environments, every project still has to use manual type differentiations on the compiler and the OS.

SFML's CMake code is rather complex, partially as a result of how it handles external libraries. In Thor, I have fewer requirements, so I could keep the CMake code relatively limited and simple. If you are interested in how the configuration code for such a project might look like, you can clone the GitHub repository.

[MorleyDev]

It's not the complexity that gets in the way for me, it's the brittleness. I've found small details of your build environment that don't make a difference to the actual building can completely break cmake, such as the afore mentioned having shell tools on a windows machine in the path.

[eXpl0it3r]

I've found small details of your build environment that don't make a difference to the actual building can completely break cmake, such as the afore mentioned having shell tools on a windows machine in the path.

I'm not sure how you've set things up, but CMake provides a different generator for the cases when the shell is included in the PATH, simply use MSYS Makefile (or similar).

I've had the same problems, though funny enough CMake went still ahead and generated a makefile for me, after pressing the configure button again.

I'm not a huge fan of CMake myself, but for the moment being it's just the next best thing you can have. The sh-issue is strange and not very nice, but I guess applications always do have some requirements.
The actual problem lies with what Nexus said. If it tries to build a bridge between all the compilers, why do we have to specify everything differently for every OS, except the final stages?
On top of that, the dependencies tracking is non-existent, which makes building applications with quite a few dependencies extremely cumbersome.

[moonfirefly]

I've been using SFML for my project in Xcode and it was beautiful so I decided to port it to windows with Code::Blocks.

Did you get XCode to bundle the dylib libraries in the application archive? my builds only contain the frameworks, test machines require SFML installed for the binaries to even start.

[MorleyDev]

I'm not sure how you've set things up, but CMake provides a different generator for the cases when the shell is included in the PATH, simply use MSYS Makefile (or similar).

MSYS version fails when ran through either cmd.exe or sh.exe

Building C object
  CMakeFiles/cmTryCompileExec2836876910.dir/testCCompiler.c.obj

  /C/MinGW/bin/gcc.exe -o
  CMakeFiles/cmTryCompileExec2836876910.dir/testCCompiler.c.obj -c
  /C/Users/Jason/Downloads/SFML-master/SFML-master/CMakeFiles/CMakeTmp/testCCompiler.c

  process_begin: CreateProcess(NULL, /C/MinGW/bin/gcc.exe -o
  CMakeFiles/cmTryCompileExec2836876910.dir/testCCompiler.c.obj -c
  /C/Users/Jason/Downloads/SFML-master/SFML-master/CMakeFiles/CMakeTmp/testCCompiler.c,
  ...) failed.

  make (e=2): The system cannot find the file specified.

This seems to be the same issue Eclipse is having with the latest Mingw version, namely it just fails to build anything without a useful output >.< I used to get around this by building an Eclipse makefile and running Eclipse headlessly, but since Eclipse started failing for the same reasons...yeeeah -__-

[eXpl0it3r]

MSYS version fails when ran through either cmd.exe or sh.exe

Not sure what you're doing then, but since I'm using different versions of MinGW, I haven't put anything into the PATH and only set the compiler bin dir whenever needed. A small batch script can do the trick...

@set "PATH=C:\Dev\MinGW32\bin;%PATH%"

This seems to be the same issue Eclipse is having with the latest Mingw version, namely it just fails to build anything without a useful output >.< I used to get around this by building an Eclipse makefile and running Eclipse headlessly, but since Eclipse started failing for the same reasons...yeeeah -__-

Have you tried reinstalling CMake? Someone here had a similar issue and a reinstall fixed it.

[MorleyDev]

Uninstalled, downloaded the zip and put it's contents on the C:\ drive so cmake.exe is in "C:\cmake\bin", whilst all the gcc/g++ compilers are in "C:\Mingw\bin".

Then executed the following commands:

Code: [Select]

@set PATH="C:\MinGW\bin"
"C:\cmake\bin\cmake" -G "MSYS Makefiles"

Output as follows

-- The C compiler identification is unknown
-- The CXX compiler identification is unknown
-- Check for working C compiler: C:/MinGW/bin/gcc.exe
-- Check for working C compiler: C:/MinGW/bin/gcc.exe -- broken
CMake Error at C:/cmake/share/cmake-2.8/Modules/CMakeTestCCompiler.cmake:61 (message):
  The C compiler "C:/MinGW/bin/gcc.exe" is not able to compile a simple test
  program.

  It fails with the following output:

   Change Dir: C:/Users/Jason/Downloads/SFML-master/CMakeFiles/CMakeTmp



  Run Build Command:C:/MinGW/bin/make.exe "cmTryCompileExec2428491674/fast"

  C:/MinGW/bin/make.exe -f
  CMakeFiles/cmTryCompileExec2428491674.dir/build.make
  CMakeFiles/cmTryCompileExec2428491674.dir/build

  make.exe[1]: Entering directory
  `C:/Users/Jason/Downloads/SFML-master/CMakeFiles/CMakeTmp'

  /C/cmake/bin/cmake.exe -E cmake_progress_report
  /C/Users/Jason/Downloads/SFML-master/CMakeFiles/CMakeTmp/CMakeFiles 1

  process_begin: CreateProcess(NULL, /C/cmake/bin/cmake.exe -E
  cmake_progress_report
  /C/Users/Jason/Downloads/SFML-master/CMakeFiles/CMakeTmp/CMakeFiles 1, ...)
  failed.

  make (e=2): The system cannot find the file specified.

  make.exe[1]: ***
  [CMakeFiles/cmTryCompileExec2428491674.dir/testCCompiler.c.obj] Error 2

  make.exe[1]: Leaving directory
  `C:/Users/Jason/Downloads/SFML-master/CMakeFiles/CMakeTmp'

  make.exe: *** [cmTryCompileExec2428491674/fast] Error 2





  CMake will not be able to correctly generate this project.
Call Stack (most recent call first):
  CMakeLists.txt:17 (project)


-- Configuring incomplete, errors occurred!

Replacing the second command with the following has the same result:

Code: [Select]

"C:\cmake\bin\cmake" -G "MinGW Makefiles" -DCMAKE_MAKE_PROGRAM="C:\Mingw\bin\make"
You know, I may be missing something obvious like a command line value xD But when I use none of that path magic and use the generator "Visual Studio 11 Makefiles" then it works fine...which would be nice if I wanted to use Visual Studio compiler. I mean, the November CDT is out so most of the features I missed from GCC are in...

But I'm not a fan of the Visual Studio compiler or the way it handles C++ at all

[eXpl0it3r]

Okay here's the thing, if you have sh.exe in your PATH you'd probably better of going with MSYS itself (thus don't use the cmd.exe but use the provided terminal).  If you don't have it in PATH then the way with cmd.exe should work, but choose as generator Makefiles.
The problem is, that MSYS and cmd.exe seem to mix 'well' on the surface (calling ls etc.) but they just don't play very nice with each other.

On my system I strictly separate the different systems (except 3rd party applications like CMake). For instance when I need to call configure for a certain makefile I switch to the MSYS terminal, since pure MinGW-GCC doesn't provide that option, but if I just want to build something with CMake, I add the bin directory of the wanted compiler to PATH (with the batch file) and the run cmake (which in fact is in PATH).
I'm even crazier an got Cygwin running (but also not in PATH) and do all my git/svn/ssh work with that, since it integrates way better.

If I should help you a bit more directly, we could make a Google Hangout or similar (I've got you already in my circles).