- Update FindSuiteSparse to use FindTBB.cmake to find TBB.
- Fix logic handling of TBB=ON if TBB is not found to continue with
build after disabling TBB rather than throwing a fatal error.
- Use TBB_LIBRARIES instead of TBB_tbb_LIBRARY as a Ceres dependency,
the former also includes the TBB malloc library.
- Add warning message about GPL licensing if TBB version < 2017.
- Add ‘TBB’ & ‘Mulithreading’ component options to find_package(Ceres),
where ‘Mulithreading’ is equivalent to ‘TBB’ || ‘OpenMP’.
Change-Id: Ifc7f1d01b050ba6e2097ad1913b178805df4769a
There are platforms where OpenMP is not available. This
patch adds support for Intel Threading Building Blocks (TBB)
as an alternative threading backend.
Change-Id: I94497d7cba0c3cfaccfc992169236f17fe948ae9
- Since the update to optionally use target_compile_features(), the
warning about Ceres propagating C++11 compile flag requirements to
clients was suppressed dependent upon the compiler option selected by
CMake to satisfy the C++11 requirements for Ceres (e.g. if using
-std=gnu++11 instead of -std=c++11).
- Now we display the warning for all CMake versions where any C++11
related flags can be exported in the Ceres target (CMake >= 2.8.12)
if Ceres was compiled with the CXX11 option enabled.
Change-Id: I5cb91e773fc7c41996b5eabadcaa295ebd7de4f7
The FindSuiteSparse.cmake refactor had a typo where CCOLAMD
and COLAMD were conflated.
Thanks to @jasjuang for reporting this issue and finding the exact
commit where this bug was introduced.
Change-Id: If8ef6624df3b8b2fd7f0861eafc4700173401435
- As reported as Issue #285, previously we passed user-specified hint
locations as PATHS to find_path/library which means that they are
searched after system locations. Now we pass them as HINTS, which are
searched before system locations.
- Also clean-up FindSuiteSparse to replace repeated code for finding
each component with a common macro.
Change-Id: I20a1f905d929a23037b1d0b7fb7ffe817abaa3e3
- Use the same logic as per gflags & glog whereby we perform (up to)
two find_package() calls such that installed packages are preferred
to exported build directories across all platforms.
Change-Id: Ifb9a7ba322ee43ed18c5774633e4bb527ce7cd75
- Use target_compile_features() to specify the C++11 dependency for
Ceres if the CXX11 option is enabled and the current CMake version
supports it (>= 3.1). Otherwise fall back onto our existing
target_compile_options() solution if available.
- We prefer the use of target_compile_features() if available as it more
gracefully handles ‘upgrading’ of the C++ standard in client projects
that depend upon Ceres, e.g. if the client requires C++14. The
current solution may fail to produce the expected result in this case
as raised in
https://github.com/ceres-solver/ceres-solver/issues/273.
Change-Id: Ib3cff8d4b9fe93fa6d6b376b4dd53923bb1c4ecc
- Updates FindEigen.cmake to default to an installed Eigen CMake
Configuration if available, otherwise falls back to previous behaviour
of searching for Eigen components.
- This mimics the behaviour of FindGflags.cmake & FindGlog.cmake.
Change-Id: Ifce948d554a0135ce1a0c443267c0230e516f14b
- Using Ceres_[SOURCE/BINARY]_DIR (which are defined by CMake when
project(Ceres) is called, in favour of CMAKE_[SOURCE/BINARY]_DIR
enables Ceres to be nested within (and built by) a larger CMake
project (which also contains other projects).
- CMAKE_[SOURCE/BINARY]_DIR always refers to the top-level source
and binary directories (i.e. the first encountered), as a result if
Ceres is a nested project within a larger project, these would not
correctly identify the source/binary directories for Ceres (as they
would refer to the root project in which Ceres is nested).
- Using Ceres_[SOURCE/BINARY]_DIR should ensure that Ceres always uses
the correct source/binary directories, irrespective of whether Ceres
is nested or not.
Change-Id: I62226ea3f6552b1d7e2bdac1aef02f1f489ae55e
- When Ceres is exported (rather than installed), the miniglog headers
still reside in the internal Ceres source directory, not the public
headers directory.
Change-Id: Ia54eb7f8bb0cd24c0112a715a739c15247bc9239
- MSVC deprecated the standard POSIX names for Bessel functions in
favour of underscore prefixed versions.
- Previously we were checking for the presence of the newer underscore
functions via a macro, which fails as the functions are not defined
as macros.
- Now we check via a check_cxx_source_compiles() if the newer underscore
prefixed versions exist when compiling on MSVC and use a new Ceres
configuration #define to switch on their presence in jet.h
Change-Id: I430880bde2981d12f4d03dbc94d903b9842e887e
- glog has a bug in its CMakeLists.txt whereby it uses ‘google-glog’ as
its project() name in its CMakeLists.txt, but exports itself as ‘glog’
which results in an install prefix on Windows which contains
‘google-glog’ instead of ‘glog’ which breaks find_package(glog).
This has been raised as a glog issue here:
https://github.com/google/glog/issues/149.
- We now force find_package(glog) to search glog using both
‘google-glog’ (for Windows) & ‘glog’ (for all other OSs).
Change-Id: I6c0edccdec405200eaa0fea1476b574e73bd3f14
- When built with CMake on Windows, the default install prefix
will be C:/Program Files/<PROJECT_NAME> (instead of /usr/local on
Linux / OS X.
- Due to an upstream change in Eigen >= 3.3, the project name for Eigen
changed to Eigen3 from Eigen, thus changing the default install
location.
- glog, uses the project name “google-glog”, thus when it is build with
CMake, this becomes it’s default install path instead of just glog
when built with other tools.
- This patch adds both of these paths to the default search list on
Windows.
Change-Id: I987b502fed0f6e685c504fd47fd504307aad8bef
- This protects against a client project which invokes
find_package(Ceres) after having called find_package(Foo) with their
own version of FindFoo.cmake which conflicts with Ceres’ exported
version and defines FOO_FOUND, but not the other variables Ceres’
FindFoo.cmake is expecting which can break the detection logic.
Change-Id: I9fe7bfa8a34bb58b09ffe34446da973912cf5587
- If gflags was built & exported with CMake but glog was not, but both
were found then as we now make gflags a public dependency of Ceres if
both it and glog are found, the *name* of the exported gflags CMake
target (gflags-shared or similar) will appear in CERES_LIBRARIES.
- However, as imported targets are not re-exported, this results in a
linker error when compiling client code, as the name of the exported
gflags target is not known to CMake, it assumes it is a library name,
which it is not.
- Confusingly, if glog was built with CMake, this problem would not
occur, as in that case glog’s CMake target would bring in gflags’.
- Now we explicitly call find_package(Gflags) in CeresConfig.cmake if
Ceres was built with gflags as a public dependency (via glog).
Change-Id: I5cc9483a1fae50f4e9e3a8fbba491b645fd45db6
- The latest version of glog supports building with CMake, in which case
it exports itself via CMake as a target that contains important meta
information such as Windows-specific compilation definitions.
- This patch updates FindGlog.cmake such that it can optionally use
an exported glog target if one exists, if not it will fall back to
the current approach whereby the glog components are found manually.
This behaviour (and the implementation) is very similar to that of
FindGflags.cmake.
Change-Id: Idfb5f49c1b457707029bff52068f58237c0e285d
- gflags_report_not_found() calls gflags_reset_find_library_prefix()
and we only reset CMAKE_FIND_LIBRARY_PREFIXES when performing a manual
search for gflags, but gflags_report_not_found() is also used
before the manual search when searching for an exported gflags target.
- As such, it was possible that we could have cleared
CMAKE_FIND_LIBRARY_PREFIXES rather than reset it if
gflags_report_not_found() was invoked during the exported target
search.
- This patch prevents this possibility by verifying that the cached
version of CMAKE_FIND_LIBRARY_PREFIXES exists before updating it.
Change-Id: I07528ae5f197a366c7da342196b3e977f9a1fc93
- Users can now specify particular components from Ceres, such as
SuiteSparse support) that must be present in a detected version of
Ceres in order for it to be reported as found by find_package().
- This allows users to specify for example that they require a version
of Ceres with SuiteSparse support at configure time, rather than
finding out only at run time that Ceres was not compiled with the
options they require.
- The list of available components are built directly from the Ceres
compile options.
- The meta-module SparseLinearAlgebraLibrary is present if at least
one sparse linear algebra backend is available.
Change-Id: I65f1ddfd7697e6dd25bb4ac7e54f5097d3ca6266
- This could result in potentially confusing output if dependencies
were found with the QUIET option: "XXX not found due to ...", followed
by "found <part of> XXX".
- If find_package() was called with REQUIRED, then a FATAL_ERROR was
triggered in the xxx_not_found() macros, resulting in early
termination.
Change-Id: Ibf59afd10067b9debd1a5e15f735a41b61bed52e
- Previously we had the Ceres version defined in two places, one in
include/ceres/version.h, and one in the main CMakeLists.
- Now the main CMakeLists reads the Ceres version directly from
version.h, as does the make_release script, so that we have a single
place (version.h) in which the current Ceres version is defined.
Change-Id: Ie80aa7d38f5b576d3ed4d6109dd699f565c91027
- Gives an option to specify a lower deployment target version than the
current SDK for backward compatibility.
Change-Id: Ieb84ba7f42cdf925510f84b8e0cd01b5e9fc051b
- If Ceres is built as a shared library, and LTO is enabled for Ceres
and the tests, then type_info::operator==() incorrectly returns false
in gtests' CheckedDowncastToActualType() in the following tests:
-- levenberg_marquardt_strategy_test.
-- gradient_checking_cost_function_test.
on at least Xcode 6 & 7 as reported here:
https://github.com/google/googletest/issues/595.
- This does not appear to be a gtest issue, but is perhaps an LLVM bug
or an RTTI shared library issue. Either way, disabling the use of
LTO when compiling the test application resolves the issue.
- Allow LTO to be enabled for GCC, if it is supported.
- Add CMake function to allow easy appending to target properties s/t
Ceres library-specific compile flags can be iteratively constructed.
Change-Id: I923e6aae4f7cefa098cf32b2f8fc19389e7918c9
- The newer style, which are more specific and match the SDK names
are not available on Xcode < 7.0.
Change-Id: I2f07a0365183d2781157cdb05fd49b30ae001ac5
- Substantial cleanup of iOS.cmake to use xcrun & xcodebuild to
determine the SDK & tool paths.
- Use libtool -static to link libraries instead of ar + ranlib, which
is not compatible with Xcode 7+, this change should be backwards
compatible to at least Xcode 6.
- Force locations of unordered_map & shared_ptr on iOS to work around
check_cxx_source_compiles() running in a forked CMake instance without
access to the variables (IOS_PLATFORM) defined by the user.
- Minor CMake style updates.
Change-Id: I5f83a60607db34d461ebe85f9dce861f53d98277
- Increasing the inline threshold results in very variable performance
improvements, and could potentially confuse users if they are trying
to set the inline threshold themselves.
- As such, we no longer export our inline threshold configuration for
Clang, but instead document how to change it in the FAQs.
Change-Id: I88e2e0001e4586ba2718535845ed1e4b1a5b72bc
- When compiled with Clang, Ceres and all of the examples are compiled
with an increased inlining-threshold, as the default value can result
in poor Eigen performance.
- Previously, client code using Ceres would typically not use an
increased inlining-threshold (unless the user has specifically added
it themselves). However, increasing the inlining threshold can result
in significant performance improvements in auto-diffed CostFunctions.
- This patch adds the inlining-threshold flags to the interface flags
for the Ceres CMake target s/t any client code using Ceres (via
CMake), and compiled with Clang, will now be compiled with the same
increased inlining threshold as used by Ceres itself.
Change-Id: I31e8f1abfda140d22e85bb48aa57f028a68a415e
- If a CMake-ified version of gflags is not detected, then
gflags_LIBRARIES is not set and the TARGET condition within a
multiconditional if() statement prevents configuration.
Change-Id: Ia92e97523d7a1478ab36539726b9540d7cfee5d0
- Updated to new CMake style where function names are all lowercase,
this will be backwards compatible as CMake function names are
case insensitive.
- Updated using Emacs' M-x unscreamify-cmake-buffer.
Change-Id: If7219816f560270e59212813aeb021353a64a0e2
- gflags <= 2.1.2 has a bug in its exported gflags-config.cmake:
https://github.com/gflags/gflags/issues/110 whereby it sets
gflags_LIBRARIES to a non-existent 'gflags' target.
- This causes linker errors if gflags is installed in a non-standard
location (as otherwise CMake resolves gflags to -lgflags which
links if gflags is installed somewhere on the current path).
- We now check for this case, and search for the correct gflags imported
target and update gflags_LIBRARIES to reference it if found, otherwise
proceed on to the original manual search to try to find gflags.
Change-Id: Iceccc3ee53c7c2010e41cc45255f966e7b13d526
- Optionally use CMake's export() functionality to export the Ceres
build directory as a package into the local CMake package registry.
- This enables the detection & use of Ceres from CMake *without*
requiring that Ceres be installed.
Change-Id: Ib5a7588446f490e1b405878475b6b1dd13accd1f
- Split out gflags namespace detection methods:
check_cxx_source_compiles() & regex, into separate functions.
- Use installed/exported gflags CMake configuration (present for
versions >= 2.1) if available, unless user expresses a preference not
to, or specifies search directories, in which case fall back to manual
search for components.
-- Prefer installed gflags CMake configurations over exported gflags
build directories on all OSs.
- Remove custom version of check_cxx_source_compiles() that attempted
to force the build type of the test project. This only worked for
NMake on Windows, not MSVC as msbuild ignored our attempts to force
the build type. Now we always use the regex method on Windows if
we cannot find an installed gflags CMake configuration which works
even on MSVC by bypassing msbuild.
- Add default search paths for gflags on Windows.
Change-Id: I083b267d97a7a5838a1314f3d41a61ae48d5a2d7
- On at least some compilers, -std=c++11 is required in order to compile
against std::shared_ptr & std::unordered_map, which resulted in our
checks failing to find them and using the TR1 versions instead, which
causes conflicts for users using C++11.
- Now, if the compiler supports it and the user enables the CXX11
option, we explicitly enable C++11 before searching for shared_ptr &
unordered_map, which means we should always find the C++11 versions
if they are available.
- As use of CXX11 results in a version of Ceres that must be used with
-std=c++11 for GCC & Clang, we roll this into the Ceres target when
the version of CMake supports this, otherwise we warn the user they
will have to do this themselves.
- CXX11 is OFF by default, to ensure that the behaviour of Ceres is
unchanged from before.
Change-Id: I157ea7a4fadc6bc02da176b8e771f1f327ccaf78
Eigen upstream was broken a little while ago, and it seemed to be
the case that we needed a fix for using the LLT factorization on
ARM.
This has been fixed and AFAIK there are no stable eigen releases
with this bug in it.
For full gore, see
http://eigen.tuxfamily.org/bz/show_bug.cgi?id=992
In light of the fix, the extra layer of indirection introduced earlier
is not needed and we are reverting to normal programming.
Change-Id: I16929d2145253b38339b573b27b6b8fabd523704
It seems that Eigen's LLT factorization is broken on ARM.
This patch enables the use of LDLT factorization instead of LLT
factorization. The switch is controlled at compile time using a
preprocessor define - CERES_USE_EIGEN_LDLT.
By default we continue to use LLT factorization though.
To make the switching easier without introducing the Cholesky factorization
based inversion and linear system solve routines have been abstracted into
two new functions.
Android.mk has been updated to enable the LDLT factorization, but
the cmake file has not been updated as I will leave it to Alex's
capable hands to do proper detection of ARM as a target platform.
Change-Id: Iffe3abd2ce894de2a388b454df3da909b482d5e5
- On MSVC, a Ceres dependency such as glog, may be named glog.lib, or
libglog.lib. By default, CMake assumes no prefix for libraries on
MSVC when using find_library(), thus find_library(glog) would fail
if glog was named libglog.lib.
- This patch caches & updates CMAKE_FIND_LIBRARY_PREFIXES in all of
Ceres' find_package scripts to include lib & "" (no prefix) on MSVC
and then returns CMAKE_FIND_LIBRARY_PREFIXES to its original state
before returning.
Change-Id: Ic82799e3b786cfb7228a51183bc189578b072bbe
In cmake 3.0, it is required to use full path for compilers. And it
seems like there's no need to force the compiler. Instead we can just
use set(CMAKE_C_COMPIER clang) so that we don't need to specify full
path of clang and clang++.
Change-Id: I9f6a625068e9d37a4bf5a595bafd82cbc13fdde4
- Add missing gflags threading dependency.
- Also add optional gflags Shlwapi dependency on Windows.
- Add check_cxx_source_compiles() with CMAKE_BUILD_TYPE to fix
namespace test builds on Windows with NMake generators.
- Add namespace regex on gflags.h when check_cxx_source_compiles()
fails on Windows using Visual Studio generator.
Change-Id: I6570c566e5a29c665d621a54935c16d16bac7117
Alex Stewart