Small refactoring in build system

[krzys_h]

I just finished a small refactoring of our build system. It's now powered by Jenkins, instead of my custom scripts.
You can access our Jenkins installation at http://compiled.colobot.info/jenkins/

What changed because of that:
1) Fixed copying of shaders into data directory
2) Language pack is now packaged together with data pack
3) Data pack builds are now triggered by commits to main code repo - this makes sure nobody forgets to update the submodule, and helps reduce bot spam on IRC
4) There are data without music and only music packages available, but not accessible directly from our main download page (you can get them here - http://compiled.colobot.info/jenkins/job...ct/output/)
5) The build system now also runs unit tests, and marks builds as unstable if they fail [TODO: this needs to be tested, but it should work]
6) We are keeping up to 15 previous binary builds and 5 previous data pack builds, in case the builds fail
7) http://compiled.colobot.info/ now redirects to our main download page
8) It should be possible to eaisly implement building of other dev-* branches

---

EDIT: Building of other dev-* branches is now implemented. They will work as soon as a new commit appears on them.

[piotrdz]

Good job

I have only one minor complaint to make: the "main" in names of builds "colobot-gold-main-dev*" is a bit confusing. I would name them simply "colobot-gold-dev*".

Now that we have our own CI server, we can use it to do some cool stuff as Jenkins has a number of plugins to display charts or tables of data. We could use it to keep track of some statistics showing our refactoring progress in code. We could add for example:
- number of TODOs left in code
- number of "naked" new/delete
- number of functions in old style, declaring variables at the beginning of function
- number of functions longer than say 200 lines
- number of violations of our coding style, like wrongly named variables

As to the problem how to generate this data, I've been playing recently with Clang's LibTooling framework. It can be used to perform static analysis on our source code using Clang's internal parser and allowing access to the generated syntax tree. When I find more time, I'll create a tool that generates at least some of these statistics.

[krzys_h]

I have only one minor complaint to make: the "main" in names of builds "colobot-gold-main-dev*" is a bit confusing. I would name them simply "colobot-gold-dev*"

It's named like that because of how the script that creates new jobs when branches are created works (https://github.com/entagen/jenkins-build-per-branch). I could probably figure something out to rename them.

The only problem is, my server has only 25 GB of HDD and huge part of it is already used, so I'm keeping only last 5 code builds and 1 data build. If we wanted to put this on main colobot.info server, that's even worse (20GB HDD, 95% used already).
If there is some plugin that removes the compiled artifacts but keeps the build metadata for statistical purposes we could use that.

[piotrdz]

I have only one minor complaint to make: the "main" in names of builds "colobot-gold-main-dev*" is a bit confusing. I would name them simply "colobot-gold-dev*"

It's named like that because of how the script that creates new jobs when branches are created works (https://github.com/entagen/jenkins-build-per-branch). I could probably figure something out to rename them.

The only problem is, my server has only 25 GB of HDD and huge part of it is already used, so I'm keeping only last 5 code builds and 1 data build. If we wanted to put this on main colobot.info server, that's even worse (20GB HDD, 95% used already).
If there is some plugin that removes the compiled artifacts but keeps the build metadata for statistical purposes we could use that.

I'll try to work something out when I have more time. I'll try to set up my own Jenkins server and see how I can configure it for such use.

Edit: I think that we should also decide if we want to keep using Travis. As I've said on IRC, it is almost useless as things stand now. The only function it had until recently was to verify that build using GCC 4.6 was not broken.

Edit: I finally found time to create the tool that I wanted - I'll write about it in a new topic.