Add Protobuf and ODE as ExternalProjects to cmake to fix platform compatibility issues #182
Conversation
Since at least Protobuf 3.21 the version is incompatible causing various include and linker errors. Maybe the incompatibility was introduced before that, but I don't know. If that is the case the version number can just be set lower than that in the future. The approach is pretty much just copied from ER-Forces framework (https://github.com/robotics-erlangen/framework) and adapted to fit the structure of this repository.
On some systems the packaged ODE (e.g. the Manjaro ode package at time of writing) causes grSim to crash almost instantly. This *may* be caused by the package having been built without double precision support, but I don't know what exactly breaks. Additionally add this as a hint to INSTALL.md.
|
For GitHub Actions, you can configure the build here: https://github.com/RoboCup-SSL/grSim/blob/master/.github/workflows/build.yaml#L33 You can remove ode and protobuf from brew installation and instead set the cmake variable to use external ODE. |
|
macos build should be fine now, I hope. |
… build protobuf correctly
Also changed vcpkg dependency from qt5 to qt5-base, because that should be enough and vcpkg seems to build from source (?) and no one has time to build Qt completely. Includes some hacks to get around the fact that the macos pipeline does not set the path to the QtConfig.cmake correctly.
|
nevermind, I was wrong, the dependencies on windows were not actually ever installed? Fixed that as well, I think. macos now also definitely works (pipeline on my fork is successful for both macos versions), but it includes a hack for the PATH to the Qt5Config.cmake, which I'm not happy about, I have no idea on how paths on macos works and especially not on macos inside a github runner. |
Apparently some weird issues are caused by using the INSTALL_DIR parameter of ExternalProjects when using the Ninja generator. Makes you wonder why that is even there, but cmake works in mysterious ways, I guess. Adding the install part as a substep and explicitly telling cmake that the necessary libs and executables are produced by this step fixes this issue.
Windows pipeline is now doing what the samples from run-vcpkg and run-cmake suggest it should do and vcpkg claims that it should handle cmake find_package calls correctly if you use their vcpkg.cmake as the toolchain. It's not working, because for some reason the find_package call for Qt still fails with cmake claiming it can't find a Qt5config.cmake file.
|
Apart from the stuff that should in theory fix the windows pipeline, but doesn't actually fix it, ODE now also gets built from source if the flag is not set, but only if find_package can't find it. |
Builds Protobuf from source if the version is too new.
I'm not sure which protobuf version was the first to break, but if someone notices an incompatibility in the future they can just adjust the maximum allowed version.
For ODE I didn't find a way to automatically detect incompatibility, because it doesn't seem to be completely dependent on the version number, but could also depend on build configurations of the package, like enabling double precision or not.
e.g. if double precision is not enabled grSim crashes instantly, but with a different error than when using the Manjaro ode package.
So it ended up as an optional flag to enable building ODE from source.
Personally I'd make building ODE from source the default, but that seems more invasive than keeping the current behavior as default.
I don't know how GitHub Actions works, so I didn't test whether the pipeline works, yet.