Automated build testing (on multiple platforms)
Closed this issue · 15 comments
I suggest adding an (online) build test setup (for example using https://travis-ci.org) to the project. travis also allows testing on different platforms (linux & os x right now, but windows is also in the making). Since you mentioned, you may not have hardware access to an os x machine, this could be one way to check if the code at least compiles and runs there, too. It also won't hurt having regular build tests done.
Definitely. I've just started using travis for another project of mine and it seems to be pretty nice.
One more thing - I understand os x support probably isn't very high on your priority list, but if you ever do think about testing (any of) your projects there - you can actually create Mac VM's (with VirtualBox), too. Example: http://lifehacker.com/5938332/how-to-run-mac-os-x-on-any-windows-pc-using-virtualbox
I took a look at building displaz in Travis. However, there is some kind of cmake bug concerning FindIlmbase.cmake version detection, which didn't seem to have an obvious workaround. When cmake fails, it does tend to be an epic fail...
$ cmake ..
-- The C compiler identification is GNU
-- The CXX compiler identification is GNU
-- Check for working C compiler: /usr/bin/gcc
-- Check for working C compiler: /usr/bin/gcc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/g++
-- Check for working CXX compiler: /usr/bin/g++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
CMake Error at /usr/share/cmake-2.8/Modules/FindPackageHandleStandardArgs.cmake:91 (MESSAGE):
FOUND_VAR (missing: REQUIRED_VARS VERSION_VAR) (Required is at least
version "1.0.1")
Call Stack (most recent call first):
/usr/share/cmake-2.8/Modules/FindPackageHandleStandardArgs.cmake:252 (_FPHSA_FAILURE_MESSAGE)
cmake/FindIlmbase.cmake:22 (find_package_handle_standard_args)
CMakeLists.txt:50 (find_package)
@chrisidefix - unfortunately testing OpenGL applications in virtualbox is pretty hopeless. For instance, I can't run the windows build of displaz inside my win7 VM because they haven't implemented various pieces of the OpenGL API.
@c42f yes absolutely agree. I tend to use Parallels or VMWare Fusion, which have more capable OpenGL implementations, but they are not free software...
The cmake on Travis is 2.8.something, which ought to suffice. But there is some kind of bug in the step that parses the version from the IlmBaseConfig.h file:
string(REGEX MATCH "[0-9]+.[0-9]+.[0-9]+" ILMBASE_VERSION_STRING ${version_line})
Which is always resulting in empty ILMBASE_VERSION_STRING. Bleh...
Fun fact, the OS X build actually works on travis 🍏
Oh, Travis is still Ubuntu 12.04, which is a fair enough baseline. I guess that displaz cmake ought to be fixed... http://docs.travis-ci.com/user/ci-environment/
Yeah, there is some advantage in forcing your users to migrate to a new version of the OS each year. :-)
@nigels-com I just checked and the REGEX MATCH appears to work fine:
message(${version_line}) gives #define ILMBASE_VERSION_STRING "2.2.0"
message(${ILMBASE_VERSION_STRING}) gives 2.2.0
I also found that REQUIRED_VARS and VERSION_VAR only exists in cmake >= 2.8.3:
http://www.cmake.org/cmake/help/v2.8.2/cmake.html#module:FindPackageHandleStandardArgs
http://www.cmake.org/cmake/help/v2.8.3/cmake.html#module:FindPackageHandleStandardArgs
travis claims it is running cmake 2.8.7so that should be sufficient as you said, but this still sounds like a CMake bug to me.
Oh cool, thanks Nigel :)
I don't understand that cmake error. Locally the ILMBASE_VERSION_STRING parsing works just fine for me (ubuntu 14.04), and it works for both IlmBase versions 1.0.1 (ancient) and 2.2.0.
Could just be an old cmake bug I guess.
Ok, I've sorted out the cmake issue. It's simply that FOUND_VAR doesn't exist in cmake-2.8.7. Fix is trivial, since I'm actually using the default without realizing it - will delete those lines.
It's pretty much working and I'll close this issue. Also see changes in PR #79 which extend the testing to OS X in Release / Debug mode. Possible extension for the future might be to also build any optional targets (e.g. unit tests).
For what it's worth, I don't think there is a legitimate notion of "optional target" when it comes to Travis. Anything that isn't being built is pretty much guaranteed to be broken.