replace nlohmann json (via git submodule) with jsoncpp (via vcpkg)
As a result, bspinfo.cc build time reduced from 2.6s to 1.9s
I only really did this switch out of concern for build times.
Disadvantages: jsoncpp development is stalled. It's a bit flaky in places, e.g. I had to add this cast to get this line to compile on macOS: model["numbrushes"] = static_cast<Json::UInt64>(src_model.brushes.size());
I think moving away from header-only is the right move, but I'm not sure if changing worth it?
Set up vcpkg in our GH Actions config, also install lua (our binaries previously lacked lua)
Disadvantage, this adds another minute or so to CI
We probably do want our maputil release binaries to be fully functional, so if it needs lua, it needs lua..
Drop appveyor
It was considerably slower (12 min, vs 3-6min for GH Actions) and we don't need it anymore (all release binaries are built on GitHub actions)
Setting up vcpkg in GH Actions was enough work that I don't feel like dealing with another CI system - this will keep being a maintenance burden every time we touch CI build settings
As a negative, if we drop appveyor, getting access to our dev builds will require login to GitHub now
We could keep appveyor as well..
Fix an ODR violation reported by GCC
It was specifically complaining about struct texdef_valve_t and struct map_entity_t
I'm not sure why this only came up now, maybe jsoncpp is leaking some warning flags, but it was a valid problem
All these (except the ODR fix) are kind of subjective, what do you think @Paril ?
Alternatively we could just keep the ODR fix, vcpkg + lua, but keep nlohmann?
model["numbrushes"] = static_cast<Json::UInt64>(src_model.brushes.size());
maputil
release binaries to be fully functional, so if it needs lua, it needs lua..struct texdef_valve_t
andstruct map_entity_t
All these (except the ODR fix) are kind of subjective, what do you think @Paril ?
Alternatively we could just keep the ODR fix, vcpkg + lua, but keep nlohmann?