Re: [Widelands-public] Status of the spice-up-cmake branch.

[Holger R. <Hol...@gm...>]

Sorry for the late reply. Starcraft 2 Beta (oh year... and work of course *blink blink*) is taking the best of me.

> 
> Basically I'm getting pretty good progress on it (now that I'm back working on it again), but there are a few things on which I can not proceed at the moment.
Your progress is mirrored in the bug reports closed on this topic. Nice to see progress! 
> 
> First there is the Automatic Code Testing feature. We had that with Scons, using a SCons/Boost test way. This is not possible using CTest (The CMake testing environment), it wants some executables for testing, the approach is fully different. As I'm new to all that, I'm basically lost at that topic, someone else might want to dive into that topic now.
I saw Jaris Mail on this topic and I elaborate here. Those unittests were done by myself to establish a base for refactoring the code to break the crazy dependencies inside the code base. I gave up on this topic though and the unittest does not compile with scons for me, so I cannot say if it still runs. It should though as the Lua code has not touched on the (few) classes that are tested which are all related to routing inside the economy code. Other changes may have touched this area and broke it. 

For what it stands now, I am not sure that this code is worth the work. If noone else is going to write tests for his/her new code we can scrap this unittest idea entirely. Also Lua offers nice test features for us (rather high level tests though, nevertheless valid tests). Especially the three test suits that I gobbled together for Lua should be runnable in a easy fashion so that nothing breaks there again. 

> 
> Second, there is OptimizePics. In Scons it was there, in trunk it currently only optimizes the pics directory. The make based approach is going to die, I'm working on a Python based script, someone will have to look at it once it hits the branch, before this goes to trunk.
I can do this. I can also write this script if you wish so. Depending on what it should do, this should be a matter of some minutes....

> 
> First, there is making GGZ mandatory. Easy to do, just some work along with the general cleanup. 
> 
> Second there is the static binary. I believe after the last mails on this mailing list regarding that, we should declare a baseline on static linking and then close this issue for the spice-up-cmake branch, as there will probably never be a common way.
I agree on those points. 

> 
> Third, MacOS AppBundles. I know basically what's behind such an AppBundle, I'll prepare something the next weeks and then I'll need a couple of testers who can spend some time in optimizing what we already have.
I can try out helping there as I am on a Mac too. I have not wrapped my head around cmake/cpack though, so I'm unsure of how much help I can be here. Also, .app packages should contain static linked binaries or bundle the libraries; I guess that is the really hard part. 

> 
> Fourth: Windows Installer Bundle: I have this working, still not on the branch as this ollides with versioning settings we are currently having. I'll work on that, and create a bundle. I can also test that basically on Wine, but we will need a couple of testers on Windows once this is done.
I cannot help here. 

> 
> Fifth: Selective building of locales. I can see the idea behind it. I'm also already thinking of a way compatible to Gentoo's LINGUAS flag. What will be the default if no preference has been selected? All languages?
yes. all languages.

Cheers,
Holger