[Bug 1183193] Review Request: ceres-solver - A non-linear least squares minimizer

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



https://bugzilla.redhat.com/show_bug.cgi?id=1183193



--- Comment #17 from Taylor Braun-Jones <taylor@xxxxxxxxxxxxxxx> ---
(In reply to Rich Mattes from comment #16)
> Have you been building in mock?  If you're building the package locally and
> happen to have a compatible BLAS package (e.g. OpenBLAS) installed, CMake
> will find and use that even if it's not what you intended..  The only way to
> be sure your dependencies and package configuration are correct is to build
> the package in mock (either locally or via koji scratch builds).

Yes, I'm building in mock, but hadn't been carefully checking the CMake output
from Ceres to see that it was being built without any sparse matrix support.
I'll be more careful about that.

> Personally, I'd probably lean towards (1) unless there's a good reason to
> use eigen instead (e.g. it's significantly faster.)  The suitesparse package
> isn't too big, and since the dependencies are taken care of by our package
> manager, there's no extra work to be done for consumers of the ceres-solver
> package.

I agree, (1) seems to make the most sense to me as well. At least for now --
Eigen is a quickly improving library compared to SuiteSparse so it may be that
it is significantly faster in the future.

> CMake configuration script location isn't mandated by Fedora, but if you
> want CMake to find the scripts you need to put them somewhere on CMake's
> search path which is documented at
> http://www.cmake.org/cmake/help/v3.0/command/find_package.html.  In this
> case, CMake would have found the package either way: <name> is
> case-independent in the applicable "/usr/share/<name>*/" CMake search path.

I guess that explains the lack of consistency I've seen with other CMake-based
packages in Fedora. I guess I'll just stick with whatever upstream uses as long
as it's one of those paths searched by find_package.

> One last thing: you might consider adding a BuildRequires on metis-devel to
> enable the optional METIS support.  metis is available in fedora and epel,
> I'm not sure what extra functionality it adds and whether it's worth it to
> include it.

Do you see ceres-solver using METIS directly somewhere? As far as I know, it
just needs SuiteSparse for the sparse matrix support.

> That being said, the package as it stands looks good, and this package is
> APPROVED.

Thanks!

Rich/Christopher - Are either of you willing to be a co-maintainer? Or added to
the InitialCC list? If so just me know your FAS username.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are always notified about changes to this product and component
_______________________________________________
package-review mailing list
package-review@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/package-review





[Index of Archives]     [Fedora Legacy]     [Fedora Desktop]     [Fedora SELinux]     [Yosemite News]     [KDE Users]     [Fedora Tools]