GHA workflow(s) for Linux

[nilsnolde]

After #9 is merged (which will fix #8), let's get a Github Actions workflow to test the bindings on Linux. That will also include setting up a manylinux docker image. The problem on Linux is that we'll need to build the bindings in an environment with a fairly low version of glibc so the binary package will be compatible with as many linux distros as possible (Mac & Win are much easier in that regard).

I personally use manylinux_2_28 these days, others have had success with manylinux2014. To preserve processing time, I prefer to publish my own manylinux image which have all OSRM dependencies installed. But to get quickly off the ground, we can also use the officially distributed image for now.

It's easiest to use cibuildwheel and configure it in pyproject.toml.

[whytro]

To drop an update on where I'm at with this, I'm currently trying to figure out how to handle setting up dependencies properly. I got it working without cibuildwheel, but I'm getting issues related to missing dependencies when using cibuildwheel and manylinux.

[nilsnolde]

Thanks for the update @whytro ! If you're up for it, we could do a short session tmrw morning (Berlin time)? I'll leave the latest around noon for a festival, but probably I can squeeze in 30 mins:) Let me know via email.

[whytro]

My findings so far:

• osrm-backend can't be "built out of the box" in manylinux_2_28, even with even with -DENABLE_CONAN=ON, due to some thrown warnings (and all warnings are treated as errors).
• Some CMakeLists changes for py-osrm need to be made in order to pass the "ignore warnings of x type" flag into the osrm-backend build.
• Python 3.8+ also needs to be built and installed from source, due to the older default version, and no newer version accessible from directly yum.
• For Conan usage, Conan needs to be installed, but the default version of Conan installed will install a version incompatible with certain flags in osrm-backend, so an older version needs to be specified (ie. 1.60.1):

  ERROR: Error while initializing options. The usage of package names `boost:filesystem_version` in options is deprecated, use a pattern like `boost/*:filesystem_version` instead
    CMake Error at build/cp311-cp311-manylinux_2_28_x86_64/_deps/libosrm-src/cmake/conan.cmake:540 (message):
      Conan install failed='1'
    Call Stack (most recent call first):
      build/cp311-cp311-manylinux_2_28_x86_64/_deps/libosrm-src/cmake/conan.cmake:882 (old_conan_cmake_install)
      build/cp311-cp311-manylinux_2_28_x86_64/_deps/libosrm-src/CMakeLists.txt:371 (conan_cmake_run)

• Some other py-osrm CMakeLists changes might be necessary to get proper linkage to LibOSRM and its dependencies as well.

Currently, I'm able to get py-osrm installed locally and its tests passing, but with above caveats (ie. osrm-backend is installed, and modified CMakeLists on py-osrm). Now to port it over to Github Actions & CIBW...

[SiarheiFedartsou]

and all warnings are treated as errors

I believe it should be possible to turn it off

[SiarheiFedartsou]

For Conan usage, Conan needs to be installed, but the default version of Conan installed will install a version incompatible with certain flags in osrm-backend, so an older version needs to be specified

in OSRM we just specify that we don’t want 2.x version via pip install <2.0

[SiarheiFedartsou]

and all warnings are treated as errors

I believe it should be possible to turn it off

Ah there is no existing CMake flag for that in OSRM, but it is trivial to add…

[whytro]

Oh yeah, I was able to get most of the aforementioned issues resolved, and get the tests running on a local manylinux image. I just set the appropriate CMAKE_CXX_FLAGS in the CMakeLists, and the other "findings" I listed were the parts I managed to resolve.

The main issue I'm facing is that while I can make it work on a local manylinux docker image, I can't seem to port it over to GitHub Actions smoothly.

The working local version was with a separate install of osrm-backend, and not using FetchContent. With FetchContent, I have this odd issue where I can find the Lua package on the py-osrm CMakeLists run, but not on the FetchContent's run.

On the other hand, when doing the separate install of osrm-backend + py-osrm on GitHub Actions, I get a ValueError: Cannot repair wheel, because required library "libtbbmalloc_proxy.so.2" could not be located-type error on the repairing wheel step.

[nilsnolde]

done in #12