ceres 3.0 build questions

[Ky Waegel]

I've been testing out the Ceres 3.0 build system (current master branch), and had a few questions. I know some of this might eventually be answered in updated build docs (ticket).

First question: it's convenient to build Ceres via CMake FetchContent()/add_subdirectory(), but it's unclear what the recommended practice is for setting configuration flags with names that conflict with the parent project. E.g. things like BUILD_TESTING, BUILD_SHARED_LIBS, BUILD_BENCHMARKS, etc.

Since option() creates global cache variables, the name collisions can be tricky to deal with. E.g. you want to build a shared library with Ceres linked statically, or build parent tests but not Ceres tests. I'm not sure if this should be fixed in the Ceres project (e.g. use a flag like 'Ceres_BUILD_SHARED_LIBS ' when built as a sub-project), or document some other recommended way to handle this case (maybe involving CMake block() to create a new variable scope before adding the Ceres source directory). I'm not aware of any native CMake mechanism to handle this.

Second question: Ceres currently builds it's own copy of Abseil (checks for source in third_party/) before checking for a system install, but maybe it would make sense to fist check for an existing 'abseil::abseil' target (or any specific absl:: targets) that may already exist in the parent project to avoid duplicate Abseil builds. I'm still trying to figure out a workaround for this one.

-Ky Waegel

[Sameer Agarwal]

+Sergiu Deitsch who is our build meister.

--
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 visit https://groups.google.com/d/msgid/ceres-solver/023ed031-3d0c-4fc3-a18c-0579e12fbfb6n%40googlegroups.com.

[Patrik Huber]

Hi all,

I haven't tried Ceres 3.0 yet but my views/comments on this:

- BUILD_SHARED_LIBS is an official CMake variable (https://cmake.org/cmake/help/latest/variable/BUILD_SHARED_LIBS.html) - this should probably not be renamed to Ceres_BUILD_SHARED_LIBS - or if it is renamed, then it should be made sure that it is populated with BUILD_SHARED_LIBS.

- The other cache variables (like BUILD_TESTING, BUILD_BENCHMARKS) should probably include Ceres (or CERES) in their name though to avoid clashes, as they are very common names.

- If Ceres 3.0 does build a local copy of Abseil before checking or allowing for a system install, this will be *very* annoying to anyone using a package manager. There is nothing worse than libraries that build their own dependencies without a way to disable it to instead use the bog-standard CMake mechanism (which is find_package in CONFIG mode!), so it will work with a package manager. Please make sure that Ceres's CMake scripts play well with package managers like vcpkg. The reality is that vcpkg (and the same is probably true for other package managers, but I only know vcpkg well) has gained so much traction by now in the C++ community that it is no longer possible to ignore it, for any library that takes itself seriously. And vcpkg-specific patches are not nice, and I believe vcpkg's guidance is that packages do need to use their dependencies from vcpkg too - for example Abseil is in vcpkg too, so Ceres in vcpkg must use Abseil from vcpkg.

I would recommend that before releasing 3.0, it's made sure that the vcpkg port of Ceres can be updated to 3.0 and still works. This may likely surface issues in Ceres's updated CMake scripts, which can then be fixed *before* a final 3.0 release.

I'm not sure I would be able to help updating the vcpkg port file of Ceres, but I would definitely be able to help test it.

Thanks a lot.

Patrik

To view this discussion visit https://groups.google.com/d/msgid/ceres-solver/CABqdRUDsmcc068zt4rALZJQ7pqpo3ao2F2wKK_AjRb%2BN%3DkrrRg%40mail.gmail.com.

[Patrik Huber]

(Small addition: I am also of the opinion that making sure your CMake build works with vcpkg is a good thing CMake-wise (beyond the scope of vcpkg) because it forces you to adhere to good CMake best-practices. If a library build doesn't work with vcpkg or needs a lot of patches to work, then it's a strong sign that the library's CMake scripts are doing things they shouldn't, and they will probably break and annoy more users than just vcpkg users.)

[Sergiu Deitsch]

We generally follow CMake best practices to make sure the common use cases are well supported. While Ceres does not provide dedicated support for FetchContent, we do not prevent anyone from using this integration method. Therefore, the recommended approach of integrating Ceres FetchContent is the same as documented by CMake.

Renaming existing and aliasing standard CMake variables (BUILD_SHARES_LIBS, BUILD_TESTING being also a CTest standard variable) by prefixing them using the project's name is not something that is on our todo list. However, starting CMake 3.13 this also seems unnecessary since you can set subproject's options using normal variables just before invoking FetchContent_MakeAvailable, ideally in a separate directory scope (see this CMake discourse thread for a reference).




To ensure that system packages are preferred over the versions provided by Ceres submodules, either do not checkout the corresponding modules or otherwise unregister them.




Finally, a heads-up to avoid confusion—our next planned release is actually version 2.3, not 3.0. I know this mix-up came up in an earlier discussion and may have been just an oversight.

Sergiu

--