Build system discussion

I've created this topic at the request of Nimbal (see this thread).

Thank you, Seregon.

I'd like to discuss our options concerning building, packaging and distributing the game. It might seem strange to some of you to talk about this already when there's little more than a prototype of the microbe stage done, but in my experience, it's really important to get this stuff out of the way first. Why? Simple. When we have a system in place to easily build a complete distribution package, ready to download and install for hobby biologists around the world, we can push out bug fixes and features very frequently. If we don't have such a system in place, packaging the software usually becomes some mysterious black magic that only select people know about. If these people become unavailable for whatever reason, the survivors are screwed. If anyone is interested in learning more about this philosophy of "build early, build often", google for "Continuous Integration". It's an important topic for any professional or aspiring programmer.

So much for the why. Now about the how. The build system currently uses CMake. I hate CMake with a passion when I need to configure it, but love it once everything works. It's the only viable option I know to "easily" (biiig quotation marks) set up a build for several platforms. Together with CPack, it can also help in packaging the built software. I'd like to set up this whole pile, so we have the boring stuff out of the way. But before I do that, there are some decisions to make.

Supported Platforms
Just to be sure, do we want to support more than Windows? If yes, I can offer some experience in writing and building software for both Linux and Windows, but someone else will have to handle OSX. If we only need Windows support, the build system can be considerably easier (I would even argue that we won't necessarily need CMake, a well-maintained Visual Studio project might suffice).

In any case, what about old 32 bit systems? At my workplace, we only compile for 64 bit platforms, which makes the build system a little simpler. But we have a different target audience there, so things may be different here.

Zip or Native Installer?
CPack can generate several forms of distribution. They can be roughly categorized as "Compressed Archives", like zip and tar, and "Native Installers". For Windows, a native installer would be the classic "Setup.exe" that copies the application's files to a directory of the user's choosing, adds shortcuts to start menu and desktop and leaves behind an uninstaller that cleans up after itself. For Linux, these native installers are distribution specific packages (deb and rpm mostly) for the respective package manager.

Both have various advantages:

• Compressed archives are slightly easier to generate for us
  
• Compressed archives extract to a single directory, no special uninstall procedure is needed to get rid of the software, just delete the directory
  
• Native installers look better (at least on Windows)
  
• Native installers can install shortcuts to start menu and / or desktop. That's actually an important point, because it gives us the flexibility to put the game's executable wherever we want, while in the compressed archive, the executable should be in the top level directory
  

So, what would you prefer?

Compiler Support
If we want to target multiple platforms, then we must be careful not to write platform-specific code. Since Visual Studio (more specifically, its compiler, MSVC) still lags behind on C++11 support, this might pose a problem. Unless we agree on using the MinGW compiler for Windows, then we'd have all the supported features that gcc can offer, which should be enough for everybody.

Concentrating on MinGW would also bring several more advantages:

• We could write automated setup scripts to initialize a build environment. That would make it easier to bring new developers on board, since they only have to execute the script and all dependencies would be installed automatically. Windows users would have to install MinGW's MSYS shell beforehand, though.
  
• Last I checked, gcc (and thus, MinGW) generates faster executables than MSVC, even for Windows.
  
• MinGW can run under Linux and still generate Windows executables ("Cross Compiling"). That would make it considerably easier to set up an dedicated build server (see next section).
  

So, do we have any programmers here that absolutely, positively want to use Visual Studio? There are some instructions out there on how to use VS together with MinGW, but I don't know how well this works.

Long Term: Dedicated Build Server
At my workplace, we use "Jenkins", a server software that builds, tests and packages our software automatically. It's awesome to implement a small fix, then press a button on Jenkins' web interface and a few minutes later, a complete installer package is available to download on our site. That's pretty much as good as it gets in terms of build system. Everything's automated and the build-package-distribute dance is executed so many times a week that the "official new release" is just some arbitrary date and not that dreaded day where everyone scrambles to check in their last-minute fixes and the designated build engineer has to work a night shift to put it all together.

We don't need such a build server for Thrive, but it would certainly help in making the programmers' (and users') lifes easier. Jenkins itself is free, but the hardware to run it on is not. We could invest in renting a small machine (I've heard good things about Amazon's EC2 service) to serve as a build system, but I wouldn't recommend it just yet. Maybe once we have a more stable developer staff and at least a basic playable game that people would actually want to try out and test regularly.

Brilliant post. I completely agree with most of what your saying, and this is the sort of thing I would have liked to set up, but I simply don't know how to do. I created the current CMake setup, but it's the first time I've ever used CMake, so it's likely to be far from optimal.

Platforms
Ideally we would like to be able to support most platforms (within reason, so 32/64 bit Windows, Unix and Mac). We don't have developers for all those systems, so our current approach is to avoid anything platform specific, and produce test builds on as many platforms as possible (currently win64 and unix). While it may be simpler to stick to windows only support (I only work on windows), this is an open source project, and we'll be excluding a huge chunk of our target audience (and potential developers) if we don't support unix.

Distribution
We've used zip distributions for now becuase that's all we know how to do (I wasn't aware of CPack until you just mentioned it). A native installer should be our eventual aim, and if it's relatively easy to setup it might be good to do so soon. That said, zip distributions are easier for testing, as there's no need to install/uninstall anything, you simply delete the old release and unzip the new one, atleast until we include a proper patching system.

Compilers
We've already decided (see this thread) to use gcc/mingw, as we would like to use some c++11 features, and also to make cross-platform support easier.

The linked thread also contains setup instructions (currently multiple versions, I need to clean that up). Having a setup script would be a huge improvement, but making one is beyond me.

When developing the current cmake build system, I tried multiple compilers, MSVS was practically impossible to setup with cmake (I know it's possible, but can't find enough info anywhere to actually do it). Eclipse CDT works ok, though I eventually settled for netbeans as our recommended windows IDE. All that said, MSVS is still my favourite IDE, but using it with MinGW just seems impractical.

Build server
I've looked into Jenkins, Buildmaster, and a few other auto-build solutions, but I'm hugely out of my depth here, partly becuase I'm fairly new to this sort of collaboration, and partly becuase I'm not a server-guy, so don't understand how to setup that side of it.

The second problem is that this project has no money, and we intend that it never will, so paying server fees will be difficult. If it turns out that this is hugely benificial (and I see that it might be), some of us may chip in to pay for it. My question then, is: how much of the functionality of a server-based build system can we provide to individual developers in script form. Or alternatively, what does Jenkins do that CMake/CPack don't. Executing unit tests is one benifit I know about, but it should be fairly simple to do that locally.

Without a build server, our workflow (I think) would look something like:
code -> commit/push to git -> compile build (for your platform) -> run unit tests -> (optionally) compile for other platforms -> upload new builds (currently to dropbox)

and with server:
code -> commit/push -> hit 'automated build' button

Obviously the second is far simpler, but the first isn't excessively difficult either. That said, the first makes continuous integration a lot tougher, as it adds a lot of steps developers won't want to do every time they commit something, so unit testing may get skipped for several commits, leading to issues.

Again, thanks for posting this. This is definately the sort of thing we should be aiming to do, but don't yet know how to.

My usual workflow with our build server at work is

1. Make a local change
   
2. Compile and test locally
   
3. Once satisfied, commit to local repository
   
4. Maybe goto 1 for additional changes
   
5. Push to central repository
   
6. Tell the build server to do its thing
   
7. Go get a tea
   
8. On the way back from the kitchen, ask the QA guy to test out the changes
   

Note that in step 2, I only build for my development platform (Ubuntu, in this case), while the build server builds for multiple platforms. This has already led to some subtle platform specific issues, but those are usually caught by our internal testers.

We also set it up so that the build server handles incrementing the version number and generating the changelog. Part of the version number string consists of the build number, which is an ever incrementing integer generated by the server. If it misses in a build, we know that it originated from a developer's machine, not the build server.

Great post. Here it is what my opinion is on each topic:

Platforms
Personally, i dont think it would be too bad if we just developed for Windows. Nearly all games run on windows, with some having suport for other platforms, so everybody wanting to play games has a windows. Developing for windows only, we would leave out only a tiny amount of potential people.

However, if we dont have too many problems to port to other platforms, there is no reason we shouldn't. As far as i know, all the code we have could be ported directly to linux. The only thing we need is set up the compiler for it, which shouldn't be too bad. I don't really know about mac, but it shouldn't be too bad either.

Distribution
Personally, i hate instalers. They start doing things all over the place. One folder on Program Files, another one inside My Documents, four more scattered inside Users. Then a few hundred new entries inside registry. A few shortcuts in the desktop, and some more inside the start menu, leaving your computer filled with folders with obscure names. And god knows what else. Plus it gices the program a chance to install unwanted stuff, like plugins for web browsers, or some processes that run on startup, lagging your computer.
Then, when you want to uninstall, the uninstaller leaves behind a few folders, and sometimes some files, filling your hard drive, and you dont know whether you can delete them, again, because of the obscure names.

A compressed archiveis easier to deal with. You can move it around, maybe to other hard drives easily. You know perfectly where the program is and how much space it takes. And there are no faulty uninstallers.

For compilers and build server, my thoughs are the same as Seregon's. But i believe that there is a chance we could get some build server for free. Correct me if i'm wrong, but the only thing we need is a computer conected to the web permanently. And i dont believe neither the web speed nor the processing power need to be too high. A computer inside an university, connected 24/7 to power and internet could work, and it would be free.

Finally, could please any programmer take a look at the codebase and comment the code? I'm 100% sure that at least half of my code could be done better, either by placing things on other places, because it can be archieved on a better way, because it is a bit obscure or any other thing. If we adress those problems earlythey can be easily fixed, but if i keep going, i will end up with a code that only i can understaund, and potentially with faults.

From what I've heard from our fans, we'd have no problem supporting a dedicated build server with donations, so long as it isn't inordinately expensive. So that's not out of the question.

Daniferrito wrote:

However, if we dont have too many problems to port to other platforms, there is no reason we shouldn't.

If we only use gcc / mingw, compiling for Linux and Windows is pretty much the same thing, so it's no problem.

Daniferrito wrote:

Personally, i hate instalers. They start doing things all over the place.

I'd prefer a simple archive as well, but in my experience, the average Joe can get dazed and confused when he has to look for the executable himself. We could also offer both, an archive and an installer with shortcuts.

Daniferrito wrote:

Then, when you want to uninstall, the uninstaller leaves behind a few folders, and sometimes some files, filling your hard drive, and you dont know whether you can delete them, again, because of the obscure names.

Note that we'll likely have a similar problem anyway because of savegames. Unless we want to go old-school and ask the user for a filename when saving, our best option is to save it to the user's platform-specific home folder. The application folder itself could be an alternative, but that breaks if the user does not have write permission there (think "parent that installed the game for their kids who don't have admin access").

Daniferrito wrote:

And i dont believe neither the web speed nor the processing power need to be too high. A computer inside an university, connected 24/7 to power and internet could work, and it would be free.

Nah, it wouldn't have to be too powerful, unless we go crazy and want to build every ten minutes. Our build server at work has a single core processor at 3.16 GHz and 1 GB of memory. It takes about 8 minutes to freshly compile our 20K lines of code and create the installer.

But wouldn't the university object repurposing their equipment like that?

Daniferrito wrote:

Finally, could please any programmer take a look at the codebase and comment the code?

I'll do that as soon as I got the build setup running, which should (hopefully) be sometime this weekend. However, I'm not familiar with OGRE, so I'll have to read up on that first.

Nimbal wrote:

If we only use gcc / mingw, compiling for Linux and Windows is pretty much the same thing, so it's no problem.

Exactly what i meant.

Nimbal wrote:

I'd prefer a simple archive as well, but in my experience, the average Joe can get dazed and confused when he has to look for the executable himself. We could also offer both, an archive and an installer with shortcuts.

Well, writing a script that unpacks the files, moves them anywhere they are wanted and creates shortcuts is really straightforward. That could work as an installer, leaving the user the option of decompressing the files himself (althrough i agree that a plain installer looks better for some users)

Nimbal wrote:

Note that we'll likely have a similar problem anyway because of savegames. Unless we want to go old-school and ask the user for a filename when saving, our best option is to save it to the user's platform-specific home folder. The application folder itself could be an alternative, but that breaks if the user does not have write permission there (think "parent that installed the game for their kids who don't have admin access").

You have a point there. Yes, savegames will probably end up somewhere else. I'll think a bit more about that.

Nimbal wrote:

Nah, it wouldn't have to be too powerful, unless we go crazy and want to build every ten minutes. Our build server at work has a single core processor at 3.16 GHz and 1 GB of memory. It takes about 8 minutes to freshly compile our 20K lines of code and create the installer.

May i ask what aplication you develop? I'm curious.

Nimbal wrote:

But wouldn't the university object repurposing their equipment like that?

They've got tons of perfectly functional computer piled there. Anyway, i was thinking on a computer of mine. And they don't really care. I can ask my uncle to let me put it there, and noone will probably touch it. Anyway, that is just an option in case we decide we want a build server.

Nimbal wrote:

I'll do that as soon as I got the build setup running, which should (hopefully) be sometime this weekend. However, I'm not familiar with OGRE, so I'll have to read up on that first.

Great to read that. PM if you have any problems with the build setup. I'll be avaible untill tuesday. Dont worry about OGRE, as long as you ignore the first 150 lines at "Thrive.cpp" you shouldn't encounter much OGRE related stuff. The part that i'm concerned about is the files inside the "entityframework" folder. You might want to read about what is an entity framework, though. I find it confusing, even after coding it myself. You can read about it at this post and the folowing post.

Alright, pending some more tests, the build system will be ready tonight. While sanitizing the CMakeLists.txt, I wondered why there are separate resources.cfg files for debug and release builds. If we keep that like it is, we'll have to remember updating both files whenever a resource is added / changed. That already caused problems when I tried to do a debug build, as the resources_d.cfg for those builds wasn't updated with a new model.

I guess one application of separate files would be to insert placeholders in the debug version to try and pin down graphics issues. However, I'd rather we mistakenly release a version with obvious placeholders (easily identified and fixed) than a version that crashes because Ogre can't find a resource we forgot to add. In at least one configuration (full screen) it didn't even display an error message, but just displayed a black screen until I pressed Escape.

Anyway, my vote is to only maintain one resources.cfg. Any counter arguments?

I'm looking forward to seeing what you've done. Having seperate resources and plugins files is leftover from the Ogre tutorials, I'm not sure we need to keep them seperate, and we'd only need to change 1 line in the code to switch it over. For now I'd say we can go with using one version for debug or release, and if we ever want to go back we can switch fairly simply again.

Ugh... cross-compiling under Linux works fine, but getting the build environment right under Windows is slowly becoming a nightmare. Subtle differences in filenames of the MinGW binaries and path shenanigans of MSYS really take the fun out of stuff like this.

Oh, and the CMake GUI doesn't support toolchain files, so I wonder if there's actually any benefit to all this. Under Windows, using the automated script will be roughly as complicated as just configuring the build environment by hand.

I don't want to quote everything on the thread so I'll say what I think after reading all the thread.

IMO, Windows and Linux would be sufficient if it isn't much harder. As it has been stated, a good part of UNIX community are developer and it could help for the project.

Having a simple build system as you explained would be really be beneficial. I have a computer that could do it to get us started. After a while we could eventually setup donation and ask for a bit of money to do it, not too much.

Here is a link to the Amazon cloud prices : http: http://aws.amazon .com/fr/ec2/pricing/#reserved
It starts at 60$ and seems to get good at 150-200$/year. Not that expensive

I don't like installer either. However simple installer that doesn't contains unwanted software and allow to disable desktop/menubar shortcut isn't that bad. I'd prefer a simple zip but I don't like install itself in stupid place like minecraft in my "C:\Users\Eric\AppData\Roaming\.minecraft" folder. It's sometime easy to forget how the simple Joe can get confused by finding a simple .exe in the bin folder. We should use an installer.

Is it possible to access what you have done yet on the build system ?

Also, do you have any experience in patch system ? Is it simple to patch the files after it has been installed ?

Really nice job, those post are really helpful.

You can see the current state of the build system in my fork, in the folder "mingw-setup". It only works under Linux though, if that.

I've got no experience with patching. At work, we just generate a new installer that overwrites the current installation (to answer Daniferrito's question, I'm working on software for professional media controllers, see 42controls.com). Of course, the installer for a game with sound, textures, videos, and so on will be prohibitively big for that approach. There are several alternatives, all of which have their ups and downs. I'll see which one is the least painful to implement while providing enough benefit.

I guess that an installer that overwrite the current installation would be sufficient for a while.

Didn't see your fork. I just created a GitHub account and installed it on my computer. I'll spend some time learning it.

Please tell us when Windows is supported.

I've just pushed the latest changes to my fork and issued a pull request to the original repository. The setup scripts can be found in the mingw_setup subdirectory along with an accompanying readme.txt containing instructions.

I've gone a little different route than originally planned and written separate scripts for Windows (in Powershell) and Linux (in bash). We'll just need to remember to update both versions if we need more libraries or similar.

Finally gave it a try!

Had a couple of unsolved problem and question along the line.

First of all, I didn't know about PowerShell and couldn't find it by searching the windows menu button. I found it in the following folder from the menu :

"Alll Program -> Accessories -> PowerShell"

It should be added to the readme.

I'm not sure about the goal of the task #3 : 3. Run the setup script.

Is it to install MinGW on the computer ? Anyway it doesn't work for me. Right-clicking and selecting Run with Powershell give me ExecutionPolicy issues and it close instantly. Had to take a screenshot to read the error. I then went in powershell, changed the ExecutionPolicy again as written and went to run the script.ps1 file from there. My PowerShell just freeze whenever I call it. It isn't buggy but I just can't do anything and it doesn't seems to be processing.Ctrl+C doesn't stop it either.

I installed MinGW myself to C:\MinGW with their installer. Everything worked fine. Added environment path variable myself.

I tried to run the Cmake config. I used a already installed 2.8 version with path added to environment.

Question, For a Windows 7 install, do I need to run :
configure_toolchain.cmake
or
toolchain_win.cmake.in

None of them succeeded even if I changed the name to toolchain.cmake.

Here is the Cmake Failing Log :

Spoiler:

I'll probably do some more tries tommorow. The readme is really clear and concise. Nice job!

RodGame wrote:

"Alll Program -> Accessories -> PowerShell"

It should be added to the readme.

Will do!

RodGame wrote:

I'm not sure about the goal of the task #3 : 3. Run the setup script.

As you already guessed, it's to install all the necessary dependencies. At the moment, those are MinGW with GCC 4.8, the Boost libraries 1.51.0 and Ogre SDK 1.8.1. The script also generates the toolchain file that tells CMake not only which compiler to use, but also where to find the dependencies. You can set all those manually, but it's a pain in the Belgium to remember and set all those paths. Anyway, I'll clarify the purpose of the script in the readme.

RodGame wrote:

My PowerShell just freeze whenever I call it. It isn't buggy but I just can't do anything and it doesn't seems to be processing.Ctrl+C doesn't stop it either.

That's strange. If it doesn't even open a dialog for directory selection, try and minimize some other windows, maybe the dialog is hiding somewhere underneath. If it freezes after selecting a directory, maybe it's downloading the dependencies, which can take a while. If that's the case, I'll have to print out a message to let the user know that at least something's happening. Unfortunately, I didn't find a way to display a progress bar or estimate the remaining time until the downloads complete.

RodGame wrote:

Question, For a Windows 7 install, do I need to run :
configure_toolchain.cmake
or
toolchain_win.cmake.in

Neither. Those are only used by the setup script to create the actual toolchain file.

Nimbal wrote:

That's strange. If it doesn't even open a dialog for directory selection, try and minimize some other windows, maybe the dialog is hiding somewhere underneath. If it freezes after selecting a directory, maybe it's downloading the dependencies, which can take a while. If that's the case, I'll have to print out a message to let the user know that at least something's happening. Unfortunately, I didn't find a way to display a progress bar or estimate the remaining time until the downloads complete.

Just did some testing and I don't think it is hiding somewhere. I alt-tabbed everything, make everything displayed then minimized everything a couple time in all way I could think of.
I don't have any dialog popping. PowerShell doesn't give me a new line starting with the current directory. There is just the cursor beeping like always and I can scroll the PowerShell. It seems like it try to open something, can't, but doesn't go to the next line in the PowerShell. It just get lost there.

Off to bed for now, I haven't said my last word to this fight yet!

All, right, I am running a Windows Vista computer with Code::Blocks, when i first tried to set it up, it did not give me an option to choose a custom path, it was a white box, (i found out later it installed into a temp directory in the folder that the set up script was in. (for setting up the MinGW compiler))

I will report back later on when i set up code blocks for it.

Ah, I've identified the problem, I think. The dialog for folder selection only works when I start the script from within the "Powershell ISE" (an IDE for Powershell). If I right-click on the script and select "Run with Powershell", I also only get a blinking cursor. I'll see what I can do about this.

@untrustedlife: Your username on your PC is not "ben", by chance, is it? I added some debugging stuff so I didn't have to select the directory every time I started the script to test it and forgot to take that out.

Nimbal wrote:

Ah, I've identified the problem, I think. The dialog for folder selection only works when I start the script from within the "Powershell ISE" (an IDE for Powershell). If I right-click on the script and select "Run with Powershell", I also only get a blinking cursor. I'll see what I can do about this.

@untrustedlife: Your username on your PC is not "ben", by chance, is it? I added some debugging stuff so I didn't have to select the directory every time I started the script to test it and forgot to take that out.

No , my username is not Ben.
I tried again,and i will explain in full the problem, it is not allowing me to choose a directory, buttons come up, but they do not do anything. Hope that helps .

@UntrstedLife
Have you tried running it from the ISE as an administrator ? It worked well for me.

@Nimbal
I opened the PowerShell ISE as you mentionned.

Executed those 2 lines :
set-executionpolicy remotesigned
E:\GitHub\Thrive\mingw_setup\setup.ps1

The dialog got hidden behind the PowerShell. Might be worth a mention to prevent user from searching it.

Along the way, I had this error. Gave you a bit before and a bit after to give you an idea of where that happened.:

Spoiler:

Also had this one :

Spoiler:

and last one which is similar to first :

Spoiler:

The script took around 8-15 minutes to process. Now everything is sitting in the "temp" folder and I have the toolchain in "cmake".

So I tried to use cmake. Reisntalled it to make sure the path was added to environment and I had the suggested version.
It fail and here is the error I'm getting :

Spoiler:

I don't know what are the variable it is talking about(i.e : CMAKE_MAKE_PROGRAM).
Also, only file in my "build/CMakeFiles" folder is "cmake.check_cache"

I'm getting there!

I'm going to try and run CMake and see what happens, the first time i tried i got many errors.So les see what happens now.

Rod, what OS and Powershell version are you using?

Could you try the following, please, just for error analysis:

1. Open a command shell (should be under Programs -> Accessories -> Command Prompt)

2. Type in "robocopy" and hit return

What's the output? "Command not found", or some help message for the robocopy program?

I'm using a legit copy of Windows 7 Home Premium.
I'm using PowerShell Version 2.0. If anyone is looking to fin his, I used the command "Get-Host" to find it.

If I'm running the cmd.exe as Administrator, I get the help information about robocopy which mean it exist on my computer.

If I run cmd.exe without administrator right, I get :
'robocopy' is not recognized as an internal or external command, operable program or batch file.

I'll try to run Cmake again as administrator but I'm pretty sure I did.

Also, I'm on the chat if you guys want to discuss it there.