Ideally we'd just say "use the default OS version" and have it
auto-upgrade as Travis upgrades their stuff, with no work on
our part. Unfortunately, Travis has let their default OSX image
lag so far back (it's now 10.13) that Homebrew has started
refusing to install GLEW without the `--build-from-source` flag.
So, sign up for some extra maintenance work.
If "make clean" on a new checkout causes diffs, you accidentally committed
one of the build products currently listed in "make clean", and you
should `git rm` it again.
If "make clean" on a dirty/built checkout causes diffs, then either
(1) the "make" process modified some tracked file which is not removed
by "make clean", i.e. either (1A) it is a build product which needs to
be `git rm`ed AND added under "make clean", or (1B) the build process
is modifying some source file, which is highly weird and shouldn't happen;
or else (2) "make" created some untracked file which is not removed
by "make clean", i.e., you should add that build product to "make clean".
The Travis build that uses "mymake" now does the same "mv" trick as Github CI,
to avoid having the executable sometimes named "./hyperrogue" and sometimes
named "./hyper". Why are these filenames different, anyway?
Fix a -Wformat bug exposed by compiling with Clang.
To preprocess C++11 code, you need `g++ -E -std=c++11`, not just
`g++ -E`. (The old code worked for GCC 6+ and Clang 6+ because they
changed the default mode from C++03 to C++14. But for GCC 5, we still
need `-std=c++11`. And regardless, it's a good idea.)
Add a "-mac" option to mymake, and cleanly factor out `set_mac`,
`set_linux`, and `set_win`. When you build mymake using
`make -f Makefile.simple mymake`, you get a mymake that knows what
platform it's on. This means you don't have to pass `mymake -mac`
on OSX, nor `mymake -win` on Windows.
The old code put `INCLUDE(___hyper-main.cpp)` into a C++ file that
would be preprocessed, which doesn't work because libSDL does
essentially `-Dmain=SDL_main`, which turns this into
`INCLUDE(___hyper-SDL_main.cpp)`, which gives us
a "file not found" error from mymake. The solution is to put
filenames into quotation marks, so that the string "main" never
appears as a token in the C++ file. (Alternatively, we could have
renamed "hyper-main.cpp" to "hypermain.cpp".)
Add several new "mymake" entries in the Travis build matrix,
and add the "mymake" builds' badge to the README.
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`).
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`.
