libosrm interface broken due to public API changes

[daniel-j-h]

Hey folks, I have someone reporting my tiny C wrapper no longer compiling against libosrm.

Looks like you folks changed the libosrm public API in

75aadb0#diff-e8cabd3a392567e2a889841a1e789cc4

which was most likely by accident.

See for context: daniel-j-h/libosrmc#11

Best,
Daniel

[gardster]

Hi!

Yes this interface was changed as a side effect on introducing new binary response format.
#5512
#5513

[daniel-j-h]

As per

https://github.com/Project-OSRM/osrm-backend/blob/master/docs/releasing.md

Minor version change
Forward-compatible C++ library API

in the previous years we used to keep the API stable during minor version releases.

If this is changing now we should update the docs and/or have a look at issues and pull requests for the major version 6 milestone https://github.com/Project-OSRM/osrm-backend/milestone/3

[gardster]

I understand your concerns.

It seems that Mapbox does not develop OSRM now. For a long time, commits from its developers does not appear and pool requests from third parties were not merged.
It’s only me who merged pull requests for the past serveral months. Alone, I don’t have enough rights to release a new version (I can’t merge self PRs without review).
I have 2 ways left. To merge the contributions from other participants to the master, checking that PR does not break the master branch and meets minimal code style requirements. Perhaps one of them will be able to get interested in the project enough to continue to support it with me and got commit right from Mapbox. Or we can freeze the API and avoid all breaking changes. But projects that are afraid to change something in their API's, usually lose their relevance and disappear.

[ghost]

Hi @gardster I am the one who raised the compile issue with @daniel-j-h's library. Please let me know what the best way to proceed is. If the changes could be isolated and enumerated, I can look into patching them with help from some colleagues, but we will definitely be much slower since we aren't very familiar with the internals of either codebase.

[gardster]

Hi @rdkt
Can you use latest official OSRM release to link with the library? Just checkout 5.22 branch instead of master one.
Or you can propose a PR in the libosrmc repository that will make it compatible with latest changes.

[akashihi]

Well, i broke it so i'll fix it: daniel-j-h/libosrmc#17

[ghost]

A colleague and I have implemented changes that make libosrmc compatible with 5.22 (it's on my fork of the repo). The code might be a little hacky since we only touched the parts needed for our application (only modifying the Python-relevant bindings), but my colleague also added support for Match. Could help get us closer to the finish line.