Previously, compiling using GCC failed with
In file included from /usr/include/c++/15.1.1/cassert:46,
from <ceres-prefix>/third_party/abseil-cpp/absl/container/internal/container_memory.h:18,
from <ceres-prefix>/third_party/abseil-cpp/absl/container/flat_hash_map.h:40,
from <ceres-prefix>/third_party/abseil-cpp/absl/flags/reflection.h:29,
from <ceres-prefix>/third_party/abseil-cpp/absl/flags/reflection.cc:16:
<ceres-prefix>/third_party/abseil-cpp/absl/container/internal/container_memory.h: In function ‘void* absl::lts_20240116::container_internal::Allocate(Alloc*, size_t)’:
<ceres-prefix>/third_party/abseil-cpp/absl/container/internal/container_memory.h:66:27: error: ‘uintptr_t’ does not name a type [-Wtemplate-body]
66 | assert(reinterpret_cast<uintptr_t>(p) % Alignment == 0 &&
| ^~~~~~~~~
<ceres-prefix>/third_party/abseil-cpp/absl/container/internal/container_memory.h:31:1: note: ‘uintptr_t’ is defined in header ‘<cstdint>’; this is probably fixable by adding ‘#include <cstdint>’
30 | #include "absl/utility/utility.h"
+++ |+#include <cstdint>
31 |
Additionally, the previous version of Abseil errouneously depends on
googletest when Ceres is consumed which results in issues with
downstream projects. We therefore update both dependencies to avoid
these issues.
Thanks to @adam-ce for figuring out the working versions of Abseil and
googletest.
Fixes#1140
Change-Id: Ie991da04491d42979d51b891a4565cabbb1c604b
Unfortunately, libc++'s 3-argument std::hypot implementation is
numerically unstable until LLVM 19.x. Therefore, checking the arguments
for zeros is insufficient since an underflow can still occur resulting
in a zero norm which requires another check. As such, division by zero
cannot be reliably avoided.
Change-Id: I189c8dc722aaec1ebc3ec8b1a177e1d8ac3b36db
Some of the benchmark functions use the same name as other functions
in the ceres namespace. For example Axpby defines both benchmark but
also an utility function in eigen_vector_ops.h. It seems to confuse
some compilers and leads to a compilation error rooting deeper into
the benchmark header itself: it seems that the compiler can not
deduct which of the instances of such functions to use.
Wrapping the file into an anonymous namespace solves the problem.
Alternative could be to use benchmark namespace to make thins more
explicit, for example ceres::internal::benchmark.
Tested on the following configuration:
- macOS 15.4
- Xcode 16.3
- Apple M3 CPU
- google-benchmark 1.9.2 installed via homebrew
Change-Id: Id127015dd22de99c6c3da88e71f255736e0bed82
Ceres CMake package configuration relies on several own find modules
(e.g., for SuiteSparse and METIS). To allow CMake to discover additional
find modules, the CMAKE_MODULE_PATH variable must be updated to include
the directories containing the corresponding find modules.
Previously, before updating CMAKE_MODULE_PATH, Ceres stored the
variable's initial value and then completely replaced it by the
directory containing Ceres's modules. However, a find_dependency failure
would cause an early return preventing CMAKE_MODULE_PATH to be restored.
Thus, any initial user changes to CMAKE_MODULE_PATH would be lost.
Now, instead of completely replacing the CMAKE_MODULE_PATH value we only
prepend additional directories. An early return no longer has a
destructive effect on CMAKE_MODULE_PATH. In a failure case,
CMAKE_MODULE_PATH still contains caller's initial set of directories and
an additional path prepended by Ceres.
Fixes#1024
Change-Id: I80d92a5dff9f3cff651f950c4f8d04ece008b44b
Recent TBB CMake package configurations do not define the
TBB_INTERFACE_VERSION variable. This causes the reported version to be
incomplete, i.e., the version looks as "(2022.0 / )". Use the CMake
specified package variable to report the identified version instead.
Change-Id: Ic7851c821217e20fd6673de5442808ea3d302f4a
CMake will print the following warning:
CMake Warning (dev) at CMakeLists.txt:n (target_link_libraries):
The library that is being linked to, ceres, is marked as being deprecated
by the owner. The message provided by the developer is:
The unscoped import target `ceres' is deprecated and will be removed in a
future Ceres Solver release. Please use the Ceres::ceres import target
instead.
This warning is for project developers. Use -Wno-dev to suppress it.
Change-Id: I5abc875b1f61e1f47523375d1579a188047c45d4
Stop linker emitting warnings such as
lto-wrapper: warning: using serial compilation of n LTRANS jobs
Change-Id: Ic933ef7b45955eabfa5b06e88cd195077ff9fc86
Using mold instead of GNU ld reduces the total build time by roughly
5-15 min. (depending on the load).
Change-Id: I66feab4e54c248cf92cc379d0085a93bdfdfef69
Use `pip install -r docs/requirements.txt` (e.g., in a virtual environment) to install Python dependencies required for building the documentation.
Change-Id: Ied9bd505bd6fc92f8c04f526ebd3ccacec306371
- Add methods to aceess the cached residuals and jacobian computed in
the optimization process in TinySolver. Usage of such methods will
retrieve the corresponding values associated with the converged
parameter.
- Reorder the Update() call to ensure that the jacobian/residuals
associated with the converged parameter are computed and cached.
Change-Id: If82e19d67d28b057833357f2c9a75b2d0fd139af
Fix the generated cmake-config file to look for the used Abseil-cpp
config files providing the needed targets.
When using Abseil from system (or locally installed and set via
`absl_DIR`) the used targets like `absl::log` need to be made available
in downstream projects using `ceres-solver`.
For system packages with no `absl_VERSION` info check for the required
target `absl::absl_vlog_is_on`, just like we do in `CMakeLists.txt`.
Error on installation/export of "no-absl-VERSION" as we can't check
version mismatches.
When using `abseil-cpp` as submodule the abseil-configs are added to the
install target as well. Use these config files to make the needed Abseil
targets available.
In the submodule case extract the `absl_VERSION` variable from its
`CMakeLists.txt` file for us to check against in the generated
cmake-config-file.
Fixes: https://github.com/ceres-solver/ceres-solver/issues/1089
Change-Id: I3e3d079ddf931e7fe1b57783471c32c19e4d31b6
Using preprocessor directives in a macro expansion is a (non-standard)
language extension that is not supported by MSVC.
Change-Id: I6e158b108a9c13cd277afb96cab2017ac192e3a2
Previously the find_package call was followed by a manual version
check because we were using a Major.Minor version. Just checking
for Major version works.
Change-Id: If83f8d1c6001d0ac3d53d9b24946b9168eb4932b
Sergiu Deitsch