Use travis-ci matrix build

[mayeut]

travis-ci is now configured for basic operation.
Time to improve & go to matrix build.

A few things to keep in mind:

• There's a 50 minutes limit per command on travis-ci so a valgrind analysis is probably not a good idea (at least a full one).
• There's an upload limit of 250MB daily (I think) on CDash. I don't know how much is 1 build... We'll need to limit the matrix size not to flood CDash & be fair with travis-ci which doesn't seem to limit number of elements.

From travis-ci documentation:

Please take into account that Travis CI is an open source service and we rely on worker boxes provided by the community. So please only specify as big a matrix as you actually need.

So, what's needed ? I'd say:

• linux gcc x86_64 Release Build
• linux gcc x86_64 Debug Build
• linux gcc i386 Release Build
• linux mingw x86_64 Release Build
• linux mingw i386 Release Build
• linux clang x86_64 ASan Debug -O1 Build
• macos clang x86_64 Release Build

Build options:

• BUILD_CODEC
• BUILD_THIRDPARTY

I think it shall cover the needs.
It also might be time to restore dev-utils folder or equivalent so that travis-ci .travis.yml doesn't become unreadable (it may already be unreadable)

[malaterre]

I'd like to see a gcc -m32 if the debian host are properly multi-arched, maybe replaced the native gcc Release with it to keep the matrix small.

[malaterre]

BTW, if time is an issue we could have:

• Lots of compilation (matrix with gcc/clang/mingw) but without any test
• Keep the full test suite for 2/3 main OS

[mayeut]

1. Unfortunately, -m32 is not supported on their linux hosts but 32 bits builds can be built on osx though.
2. The time limit is per matrix-element so there may be no need not to run tests.
3. I don't think mingw is supported out of the box on their hosts

I'll update the first post to keep a un to date proposed matrix there.

[malaterre]

Meant to say cross building with mingw, eg:

https://packages.debian.org/jessie/mingw-w64

[mayeut]

There are multiple environment on travis-ci.
By default, sudo is disabled, so no way to install packages.
Need to check how to change environment so that sudo is supported (this would allow for gcc -m32as well).

[mayeut]

travis-ci documentation is misleading... apt is supported (marked BETA in logs though).
gcc -m32 and x86_64-w64-mingw32-gcc are working.
Matrix updated in first post.

The AddressSanitizer build in Debug configuration is really slower than what I had imagined .
I think it's best to add -O1 for this build but then, Debug configuration will have no real meaning ?
We could change one of the existing build to Debug or add a new build in Debug (& check how much time it takes without ASan)

[detonin]

@mayeut
Thanks for gathering the build matrix needs. I think the proposed matrix is ok but would add indeed a Debug configuration without ASan.

[mayeut]

@detonin,

Added linux gcc x86_64 Debug Build
PR #584 up to date with the proposed matrix.

The configuration for all builds is:
BUILD_TESTING:BOOL=TRUE (except for mingw)
BUILD_THIRDPARTY:BOOL=TRUE

[malaterre]

depending on how much time we have, debian uses binfmt to execute process. In this case wine would need to be installed, I used to have a machine setup this way (testing was on).

[malaterre]

Long story short, you may have to install wine-unstable instead of wine (http://bugs.debian.org/741592) to run a portion of the test-suite sucessfully.

[mayeut]

@malaterre,

I tried to install wine on my ubuntu 14.04 VM. it seemed to work well with the test suite, however it requires about 700MB of packages to be installed as well as interactive acceptance of some EULA for fonts (It might be possible to accept those by default in non-interactive mode).
As far as I understood travis-ci apt add-on, it would download & install wine on all linux builds thus slowing down builds.
Do you know of any "wine-minimal" alternative package ? (disable all GUI stuff at least)

[mayeut]

What cmake options shall be enabled ?
Updated the ones already used in 1st post

[malaterre]

Could we get close to what used to be in the old svn devscripts directory ?

[detonin]

Shall we import this dev-scripts folder in master ?

[mayeut]

I merged PR #584 in master branch.
Not closing the issue yet if someone has other ideas.

[mayeut]

I added PR #627 which does the same thing for Appveyor.
It also includes PR #626 which was done for #600 (ABI check).
I really think the dev-scripts shall be updated now. @malaterre, if you have any suggestions on how to do this, I'd be happy to hear them.

[malaterre]

can we close #581 now that #628 is open ?

[mayeut]

@malaterre, if you consider #627 can be merged in as is, then yes.

[mayeut]

#626 and #627 merged in.