FTBFS with clang 3.6

[Hans Joachim Desserud]

Attempted to build r7439 from source with clang-3.6:
$ cmake -DCMAKE_C_COMPILER=clang-3.6 -DCMAKE_CXX_COMPILER=clang++-3.6 ..
$ make

but ran into the following error (in addition to plenty of warnings):
/home/debian/widelands/src/ui_fsmenu/main.cc:34:23: error: field 'vbox' is uninitialized when used here [-Werror,-Wuninitialized]
                  m_butw, get_h() - vbox.get_y(), m_padding),
                                    ^
1 warning and 1 error generated.
make[2]: *** [src/ui_fsmenu/CMakeFiles/ui_fsmenu.dir/main.cc.o] Error 1
make[1]: *** [src/ui_fsmenu/CMakeFiles/ui_fsmenu.dir/all] Error 2
make: *** [all] Error 2

There might be more issues since at least cppcheck has reported that various fields are uninitialized for a long time. Not sure why we haven't seen this before. Either clang-3.6 does a more thorough check, or no one has built the game from scratch with clang in a while. (According to bug 1258667, it went completely fine to build the game with clang-3.5 last September)

[Hans Joachim Desserud (hjd)]

I did some research along the lines of how could we have known and caught this sooner, so I've set up a new PPA [1]. It is similar to the regular PPA, except it adds clang to the build dependencies and forces compilation to happen with clang and clang++. (It should be noted that it probably doesn't follow best practices on how to do this because a package should really use whatever the default compiler is on the system, but it works).

At the moment it is set up to build with Ubuntu 14.04, 14.10 and the upcoming Vivid release which will presumably turn into 15.04 later this month. As luck would have it, this corresponds to clang 3.4, 3.5 and 3.6 respectively. (We'll lose 3.5 in some months time when 14.10 reaches end of life, but still...) This should allow us to follow the current state and react sooner when something breaks in trunk.

Thanks to this research it also became clear that it was in fact clang 3.6 with some stricter rules/parsing/something which broke this.

For the meantime the PPA is owned by me, but long-term we might want to move ownership to widelands-dev. Part of the reason I didn't do this immediately is that a) it is broken and b) I wanted to clearly mark it as unoffical. I like the dialy-PPA we have at the moment which is a single place you can go to fetch the latest development release. It could be argued that a clang-PPA with latest packages would be equivalent but I don't see any way it won't end up being stored separately, and I'd rather avoid the "which-PPA-should-I-use" and "I-have-this,do-you-have-that-are-they-compatible" confusion. But we can discuss this part.

PS. How I picked the name for the PPA? 50% tale of the canaries in the coal mines and 50% alliterations are always awesome!

[1] https://code.launchpad.net/~hjd/+recipe/widelands-clang-compilation-canary

[SirVer (sirver)]

> Thanks to this research it also became clear that it was in fact clang 3.6 with some stricter rules/parsing/something which broke this.

I think that is to be expected - a new compiler version will always break something in trunk - especially since we opt in into all warnings and then opt out one by one. I do not worry about these breaks - I am very excited about clang 3.6 though :).

[Hans Joachim Desserud (hjd)]

>a new compiler version will always break something in trunk - especially since we opt in into all warnings and then opt out one by one.

New warnings which catch issues we didn't know about and existing warnings which get better won't break anything in and of themselves. Though, some have been marked in CMakeLists to be treated as errors if they occur, which might happen when a newer version has tighter checks. (I don't know how we plan to deal with false positives for these, but we'll cross that bridge if we ever get there.)

Thanks for the patch. I've started another build with the clang-canary for verification.

[SirVer (sirver)]

Fixed in r7445.

[GunChleoc (gunchleoc)]

Fixed in build19-rc1.