The `HYPERROGUE_USE_ROGUEVIZ=1` build now uses inline variables.
So we pass `-std=c++17` in the Makefile. But GCC 5.4.0 (Travis's
default system compiler on Ubuntu Xenial) doesn't recognize
inline variables even in `-std=c++17` mode. Therefore, we must
pass `dist: bionic` to Travis, to get it to use Ubuntu Bionic,
whose system compiler is GCC 7.4.0. But we do this only for the
one entry in the build matrix that builds RogueViz with GCC
on Linux. Nobody else needs `dist: bionic`.
The bug was that my hack to support `g++-5` accidentally prevented
Travis from ever using `clang++`! So all our "Clang" builds were quietly
using regular `g++` instead. This is now fixed, and in fact I've removed
the `g++-5` build because its GCC 5.5.0 is not significantly different
from the regular `g++` build's GCC 5.4.0.
Also, add two more configurations to the build matrix.
Since `HYPERROGUE_USE_ROGUEVIZ=1` now uses `-std=c++17`, we want to
make sure that we run builds on every platform both with `HYPERROGUE_USE_ROGUEVIZ=1`
(to prove that the RogueViz code compiles) and without (to prove that
the non-RogueViz code still compiles as `-std=c++11`).
However, this does not unbreak the build on Emscripten.
Emscripten doesn't know where to find <zlib.h> at all:
./sysconfig.h:429:10: fatal error: 'zlib.h' file not found
#include <zlib.h>
^~~~~~~~
We must avoid the following features:
- the `using` syntax for typedefs
- alias templates (so, rename `hyper_function` to `function`)
- the `override` keyword
- defaulted virtual destructors
For testing the emscripten build in TravisCI, it looks like some
arcane combination of node + Browserify + the wasmify plugin + maybe
some other stuff *might* work, but I have no real idea yet.
For grabbing the build artifacts from Travis, you can temporarily
insert lines into the .travis.yml such as
curl --upload-file ./hyper.html https://transfer.sh/hyper.html
curl --upload-file ./hyper.js https://transfer.sh/hyper.js
curl --upload-file ./hyper.wasm https://transfer.sh/hyper.wasm
However, "hyper.wasm" is about 2.8 megabytes in size, so this hack
definitely should never become part of the *master* `.travis.yml`.
