Detecting libraries emits non-fatal errors

21 views
Skip to first unread message

Ky Waegel

unread,
Mar 7, 2024, 3:44:02 PMMar 7
to Ceres Solver
Not sure if this needs to be fixed upstream, but it's an issue I just encountered that I thought warranted discussion.

We recently upgraded to Ceres v2.2 (from 2.0), and apparently there was a change in how SuiteSparse is detected, now requiring v4.5.6 as the minimum version. This is fine on it's own, but failing to detect SuiteSparse (or finding an older version) is a non-fatal error.

The issue I ran into is that our CI system had an older version of SuiteSparse configured, so it "silently" (log message, but not a build failure) started building Ceres without SuiteSparse.

I'm not sure this is enough of a problem to change long-standing patterns in how Ceres detects libraries, but it seems like something that might bite other people.

To avoid future surprises like this, I'm going to modify our fork of Ceres to report fatal errors if a library is requested but not found. e.g. something like:
message(FATAL_ERROR "-- Did not find all SuiteSparse dependencies. Fix or set SUITESPARSE=OFF")

-Ky Waegel

Sergiu Deitsch

unread,
Mar 8, 2024, 3:10:37 PMMar 8
to ceres-...@googlegroups.com
This is expected. An incompatible package version in CMake does not produce a fatal error unless the package is required. This is not the case for SuiteSparse as it is an optional dependency.

You can set CMAKE_REQUIRE_FIND_PACKAGE_SuiteSparse to ON to ensure SuiteSparse is always used. No patching is necessary.

--
You received this message because you are subscribed to the Google Groups "Ceres Solver" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ceres-solver...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ceres-solver/3e4dfc07-4a29-41e2-a75c-6c1dd16b45d4n%40googlegroups.com.
Reply all
Reply to author
Forward
0 new messages