Proper libosrm API without aliasing header and external -> internal dependencies

[daniel-j-h]

Currently we provide aliasing header for our public API. This is ugly as it is confusing to the user, requires us to implement include path hack for the public API's headers to work at all (which by the way pollutes the users includes: when we're using osrm/X and there's a library called X we cause problems).

We do this since not only our internal headers depend on the external ones (which is fine), but in addition, our external headers also depend on our internal ones (which is ugly and nothing more than a hack). This requires us to e.g. chase down the base_parameters.hpp include headers and also install the hint.hpp header and its includes onto the user's system.

For a clean solution, the public libosrm headers must not know about the internal headers at all.
This requires us re-thinking and properly designing the API (e.g. how to break dependencies for the hints: context object, void*?) but would result in a clean and useful libosrm shared library.

[TheMarex]

I think we should delay here to 5.1.0. This is a pain to do right and doesn't win us anything immediately.

[TheMarex]

@daniel-j-h if we would move engine:: into osrm:: and make coordinate.hpp header only, this should yield something that does not break the include/<Library name> scheme, which would allow use to remove the extra include path, right?

[daniel-j-h]

Do you mean only renaming namespaces? We still have to ship e.g. typedefs.hpp because some API header requires it. Same for phantom_node.hpp and so on. Just check the output of

find /usr/local/include/osrm/ -type f -name '*.hpp'

(or where ever you installed libosrm to)

[TheMarex]

@daniel-j-h yes namespaces and like the directory structure.

• We can make Hint not depend on PhantomNode by saving individual fields so we can construct a phantom node from it. (e.g. we can compute the weight/offset at runtime) What we basically need to mirror is a EdgeBasedNode.
• typedefs.hpp needs to die. Each interface should specify its own ID type. (static_graph.hpp, dynamic_graph.hpp, ...)