berndpfrommer
commented
2 years ago So here is what I find in the gtsam config files when I install gtsam from a farm-built Ubuntu package:
./config.h:#define GTSAM_EIGEN_VERSION_WORLD 3
./config.h:#define GTSAM_EIGEN_VERSION_MAJOR 3
./config.h:#define GTSAM_EIGEN_VERSION_MINOR 7but for building locally with the new libeigen-dev 3.4.0 the gtsam config file has this:
./config.h:#define GTSAM_EIGEN_VERSION_WORLD 3
./config.h:#define GTSAM_EIGEN_VERSION_MAJOR 4
./config.h:/* #undef GTSAM_EIGEN_VERSION_MINOR */So I guess "world" equates to "major" (first number) in normal parlance, and "major" to minor (second number), and "minor" to micro (third number).
When I try to compile a GTSAM application on Ubuntu 20.04 using libgtsam-dev (both with the nightly dev build and the 4.0 release) I get the following error:
Indeed, it looks like libeigen3 has been upgraded very recently:
In theory it should work with the nightly dev build package because that one should always build under the latest version of Ubuntu 20.04. Alas, the nightly build did not run (again because github stops running the build process every 60 days, I have restarted it) and so there was a version mismatch which results in the above error. But even if the automated process had been running: we don't rebuild nightly if the Eigen version is updated. We only rebuild when GTSAM has new commits.
So what's the problem? The way the check works right now (checking for a particular version rather than demanding a minimum version of Eigen) means that whenever the Eigen folks upgrade their ubuntu library version, we will have to rebuild GTSAM and also bump the GTSAM version number such that a new GTSAM package is built and installed as well. I don't know how to learn about version changes in third party libraries, and how to trigger an automated version upgrade of GTSAM. I suspect it's hard because it's not supposed to be necessary.
From what I understand: unless the Eigen folks bump the major version number of their library (which they didn't), they are implicitly promising that their new version behaves exactly the same as the previous one, no ABI change (I'm admittedly confused what that exactly means in the context of a headers-only library). This convention permeates the entire packaging world. I believe that by asserting on equal version number we are breaking that convention.
Is that assertion for version number equality still warranted or is that a legacy check because in the past there was a minor version change that broke GTSAM? Can it be replaced with a "greater or equal" check (somewhat optimistically because we may not have tested at all against the very latest release version of Eigen)? Any other suggestions?
(referencing @jlblancoc)