restore "red X" build failures in Travis

[jeffdonahue]

...and other travis cleanup.

A while ago I moved the Travis build into scripts under ./scripts/travis, and in doing so I caused build failures (e.g. compilation errors, lint errors) to show up as "gray" rather than "red". I still don't really know why this is, as according to the Travis documentation, any non-zero exit codes returned by a command under script: should result in the red build failures. It's also unclear to me why I need the || return 1 after travis_build_and_test.sh -- it seems redundant -- but without it I see the gray Travis failures, so...

[jeffdonahue]

Somehow this breaks the CMake build...

Linking CXX shared library libpycaffe.so
/usr/bin/ld: ../lib/libcaffe.a(common.cpp.o): relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a shared object; recompile with -fPIC

not sure what to make of that, I'll look at this later.

[jeffdonahue]

Turns out that the CMake problem with building pycaffe was, I think, a bug in the CMake build, occurring because it had a hidden dependency on the CXX_FLAGS including -fPIC.

.travis.yml did source scripts/travis/travis_install.sh, which contained export CXX_FLAGS=-fPIC (used for gflags). So when I changed the sourceing of that script to directly call it instead, the environment variable didn't take effect outside the build script. To fix this I added -fPIC to CMAKE_CXX_FLAGS in f036ef4. (The first commit, which breaks the CMake build, nicely demonstrates the restoration of the red X on build failures.)