This swaps the optimization levels used by default and alternate
configurations, so that gcc gets -O0, so the compiler will do
less work. gcc does not run the wml unit tests so this should
definitely save time.
This moves the gcc 4.8 upgrade step to the "install" phase after
we run apt-get update, so that we only do that once. It can take
15 sec or so apparently to execute that command.
The alternate clang build currently uses strict compilation = false,
this was requested so that we get as many error messages as possible.
We would also like to have an -O0 build run against the unit tests,
as sometimes -O0 will segfault while -O2 won't, etc. So in this
commit the alternate build uses that option also. I also rename
the environment variables, so that the build matrix is based on
casing out whether "alternate_configuration" is true (not strict_
compilation) as previously, and the alternate_configuration flag
leads to options being exported in the before_install phase.
It seems that we cannot avoid the segfault without adding gcc-4.8
download and install to the test sequence, but this seems to push
us over the time limit consistently. In this commit, go back to
using gcc-4.8 but disable everything but the wesnoth target itself
for the gcc build to save time.
The gcc-4.8 patch requires travis to download and install gcc-4.8
from an ubuntu ppa. This takes a few mintues and the gcc build is
already fairly close to the timelimit, so this change can push
some builds over the edge. Since it doesn't seem to be strictly
necessary right now, I comment out the code for v 4.8 install.
This was buggy and based on deprecated SDL features that will not
continue to be available. aquileia wrote us a very nice windows
port of the run_wml_tests bash script, so for windows mac and
linux we should now be able to run the unit tests as desired.
Maybe someday built-in timeouts can be supported using boost
process library, if that ever materializes.
This is to combat what are apparently transient timeout faults
where the travis workers choke on running ./test and never
actually start the process... it seems not even to get to the
"running 140 tests" message when it ends with error code 200.
