Hi there. I'm using libosrm with a simple consumer code that comes down to something like:
osrm::EngineConfig config;
osrm::OSRM osrm(config);
osrm::TableParameters params;
// Fill params with coordinates
osrm::json::Object result;
osrm::Status status = osrm.Table(params, result);
This works perfectly against tagged versions of OSRM up to v5.22.0, but fails when building libosrm from current master with something like:
error: no matching function for call to ‘osrm::OSRM::Table(osrm::engine::api::TableParameters&, osrm::util::json::Object&) const’
osrm::Status status = _osrm.Table(params, result);
^
/usr/local/include/osrm/osrm.hpp:96:12: note: candidate: osrm::engine::Status osrm::OSRM::Table(const osrm::engine::api::TableParameters&, osrm::engine::api::ResultT&) const
Status Table(const TableParameters ¶meters, osrm::engine::api::ResultT &result) const;
^~~~~
Indeed, the Table interface has been changed in this commit.
I didn't dig enough to know whether switching from osrm::json::Object to osrm::engine::api::ResultT would be straithforward, but this looks like a breaking change anyway. All builds relying on previous libosrm interface will fail in the same way if this change makes it into a release.
FWIW, original problem spotted at VROOM-Project/vroom#344.
Hi there. I'm using
libosrmwith a simple consumer code that comes down to something like:This works perfectly against tagged versions of OSRM up to
v5.22.0, but fails when buildinglibosrmfrom currentmasterwith something like:Indeed, the
Tableinterface has been changed in this commit.I didn't dig enough to know whether switching from
osrm::json::Objecttoosrm::engine::api::ResultTwould be straithforward, but this looks like a breaking change anyway. All builds relying on previouslibosrminterface will fail in the same way if this change makes it into a release.FWIW, original problem spotted at VROOM-Project/vroom#344.