search

TanPinDa / VINS-Mono

A Robust and Versatile Monocular Visual-Inertial State Estimator
GNU General Public License v3.0
1 stars 0 forks source link

Fix improper handling of glog dependency in ceres-solver #9

Closed KeeJin closed 3 months ago

KeeJin commented 3 months ago

Problem

Ceres-solver depends on an older version of glog which was not cmake friendly. If multiple packages downstream of ceres-solver calls find_package(Ceres REQUIRED), the compiler will complain: 

add_library cannot create imported target "glog::glog" because another target with the same name already exists.

This problem has been caught in #7.

This problem has been mentioned in a couple of issues:

How to fix

The latest version of glog might resolve this problem, but it requires a more recent version of cmake (>3.22) that is not available in the focal apt servers. To install cmake from https://cmake.org/download/, I would have to first purge the pre-existing cmake apt package in the system. This gets messy because ros-noetic and libboost both rely on that cmake apt package, and will be removed when purging cmake. Which means I will have to re-install everything again..

Considering all these, I am proposing a simple patch to the FindGlog.Cmake to ensure that the glog::glog target does not get created more than once. The .patch file will be commited to this repo, and will be applied to the ceres-solver repo in install-deps.sh

TanPinDa commented 3 months ago

As discussed, we have come to the following options:

  1. Fork ceres-solver, and patch the Cmake. (Request PR to ceres-solver, but unlikely to be entertained because only needed for old environments)
  2. In the install dependencies.sh, we manually edit the CMake in ceres to patch it
  3. Stick with current workaround, whereby in our package, we edit the cmake so the ceres (and hence glog) is not found twice.
  4. Create new docker image, that is Jammy + Noetic (https://answers.ros.org/question/400202/noetic-on-jammy/)
  5. Create new docker image, that is Focal + Noetic (With cmake 3.22)

For now, we will stick with option 3, continue progress on VINS-mono. Slowly work on this in the background, or re-prioritise when it rears its ugly head again.