boost 1.70 breaks important linux distros

[nilsnolde]

in #6113 boost was upgraded to 1.70 which breaks quite a few important linuxes, e.g. ubuntu 18.04 (EOL 2023, v1.65), debian 10 (EOL 2022, v1.67), CentOS 9 (latest, v1.66). in our specific case we wanted to update https://github.com/enricodvn/pyosrm, the python OSRM bindings, and to build linux bindings it's really best to use a manylinux tag. the most up-to-date system for manylinux compatible builds is debian 9 with boost v1.61.

since it seems that the changes in #6113 were mainly for the server component, it'd be nice to optionally disable including the server stuff to just build the main library (actually it seems generally not to be supported yet to just build "the" library it seems, it always builds the osrm-* executables no matter what?). I'm not most a cmake wizard, but would it be accepted to aim for smth more modular? if so, would anyone else with more cmake experience be interested and willing to team up?

[nilsnolde]

I also checked on andorra: the commit before upgrading boost works fine with the lastest pyosrm (relief!, the last commit is almost 2 years ago).

[mjjbell]

It sounds like an ENABLE_SERVER or even an ENABLE_EXECUTABLES option could be provided to cmake, which enables/disables building osrm-routed or osrm-* executables respectively.

Then the required Boost version could be conditional on this option.

Valhalla appears to do something similar by splitting its dependencies by tools/data tools/services: https://github.com/valhalla/valhalla/blob/c1216e6d555e0c6e2b542a4d1a71ae9deb5f2a28/CMakeLists.txt#L220-L237

[nilsnolde]

Exactly the example I was thinking about:) Valhalla is very strictly modular, but also driven by its dependencies. Would be quite a change in cmake setup. I’ll give it a shot soonish.