Add .travis.yml for continuous integration.

[sonph]

As discussed in #5, this PR is for adding a basic travis config file.

A couple of things to note:

1. All builds are still broken. For the two linux builds with gcc and clang, I'll leave it to you as I have no idea how to fix those. For the two mac builds, the master head commit e149675 seems to be breaking the build. Reverting it fixes the problem.
2. I'm removing Doxygen.cmake out of libchaos/CMakeLists.txt as it requires latex as a temporary workaround. I tried installing mactex via brew, but the build always times out. Ideally we should have someway to disable building documentation?
3. Not sure if I'm exporting CMAKE_INCLUDE_PATH and CMAKE_LIBRARY_PATH for macOS the right way but it works. If that's wrong I'll fix it.

[theyy29]

It looks like the gcc build (on linux at least) is failing because gcc is too old.

-- Check for working CXX compiler: /usr/bin/g++-4.8

And there are some flags that require a newer gcc:

cc1plus: error: -Werror=delete-incomplete: no option -Wdelete-incomplete

On a side note, I am really not sure how travis-ci manages versions, because above that was:

$ gcc --version gcc (Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3

This flag appears to exist starting in gcc-5.1.0 according to gnu docs.

So I guess if there was a way to specify a minimum compiler version, that would be the way to fix it. It does look like you specify gcc-4.8 in the yml.

---

On a different note, it looks like the OSX gcc build is actually building with some form of clang... It even fails with the same error as the OSX clang build does, as opposed to the linux gcc errors.

---

Pinging @ChaoticConundrum because he doesn't get notifications on new issues...

[sonph]

Following your gnu docs link seems like the flag actually exists since 4.9.0. I upgraded to 4.9 and the flag error is gone 🍺

On a side note travis uses gcc 4.6.3 by default, and I don't think there is currently a way to specify the compiler version in the yaml other than installing it from the ppa. See travis-ci#6300. The gcc --version you see is travis' default gcc. In before_install I export the newer gcc version.

[theyy29]

Is there any way you could get it to have a newer version of libpng available as well? The signature of the png_sig_cmp function has changed in newer versions (namely, to have png_const_bytep instead of the png_bytep apparant in the travis-ci build errors.):

png_sig_cmp(png_const_bytep sig, png_size_t start, png_size_t num_to_check)

I believe this changed going into libpng1.5.0, which would be the minimum dependency version then. Alternatively, libchaos could be patched with an #ifdef to support both, differing only on a cast.

Can you specify the minumum version of libpng with travis-ci?

[theyy29]

I also made a change that should fix the errors being seen on the OSX builds. Its on master now (dfced55a3f16...).

[sonph]

The mac builds are now passing.

Pok3rtool does not use the zpng component of libchaos, does it? If not we should just disable it.

Travis only supports precise (12.04) and trusty (14.04) for now, so I agree it's a pain to have to find and install newer versions of everything. See travis-ci#5972 for example.

[ChaoticEnigma]

Thank you for all the help here. I am working on adding travis to the libchaos repository first, since if pok3rtool fails to build, it is most likely because of a build problem with libchaos.

As for doxygen / latex, they are only enabled if they are found, and documentation is only built if the doxygen or doxygen_pdf targets are explicitly run, because they are fairly slow.

Pok3rtool does not need any of the image libraries, so they could be disabled. See libchaos/cmake/Options.cmake. Adding -D DISABLE_ZPNG=1 -D DISABLE_ZJPEG=1 -D DISABLE_ZWEBP=1 to the cmake line will do this. I will still have to fix the build in libchaos...

[ChaoticEnigma]

Haha, I'm trying to build libchaos with travis right now, hitting api changes with libpng, libjpeg, and now sqlite3, just as you added 98fd724. Working on it!

[sonph]

Sweet :beers: