-
-
Notifications
You must be signed in to change notification settings - Fork 12.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ceres-solver 2.0.0 #63596
ceres-solver 2.0.0 #63596
Conversation
opencv, opencv@3, and rawtoaces need revision bumps. Should cmake instead be a build-only dependency? |
This also needs some more changes to the formula due to changes in how ceres handles dependencies. I have locally had success to build the ceres formula, but I'm stuck with the dependent formulas:
Yes. These don't build with the latest release ceres, in fact. They might need small changes in cmake. But the bigger issue is that ceres 2.0.0 now requires C++14, and opencv 4 is built in C++11 mode, opencv@3 in C++99 mode. It is possible to build these formulas with C++14 with small changes, but it's untested and it might affect users (there may be binary incompatibility between c++99 and c++11, I guess). I see the following alternatives:
Any suggestions which way to go here?
I think so. |
0211029
to
f31f742
Compare
964a231
to
15e278a
Compare
I'd say that this justifies including an ceres-solver@1 formula, given that it is a dependency of the quite popular opencv which (correct me if I'm wrong) is still being maintained. Presumably the opencv maintainers would fix any problems in their own repo if there were issues with ceres-solver 1.14. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is no issue to bump C++ version for OpenCV binaries if platforms used with Homebrew support that (it is compiler limitation only).
Bumping C++ version in user applications is not required, but we need to ensure "std" ABI compatibility during C++98 => C++11 change on HomeBrew supported platforms (std::string
/std::vector
/std::shared_ptr
are used in OpenCV ABI).
Formula/opencv.rb
Outdated
@@ -120,7 +123,7 @@ def install | |||
return 0; | |||
} | |||
EOS | |||
system ENV.cxx, "-std=c++11", "test.cpp", "-I#{include}/opencv4", | |||
system ENV.cxx, "-std=c++14", "test.cpp", "-I#{include}/opencv4", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No need to bump C++ version for User applications.
It is not necessary with modern compilers (last known incompatibility was with GCC 5.x, C++98/C++11 and _GLIBCXX_USE_CXX11_ABI
macro).
(BTW, this test.cpp
doesn't use OpenCV binaries, like .so/.dylib)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, makes sense, thanks. With your upstream changes in opencv I probably don't have to change anything about the formula here.
This pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. |
Sorry, I've been very busy at work lately. Thanks for you assessment, that is great, but even better would be if we can actually fix the depending formulas to use ceres 2.0. It looks much more likely than I originally thought: There was some movement at opencv to make the contrib modules using ceres compatible with version 2.0. I'm not sure when the next release will be though. Possibly in a few months. In the meantime we could consider including the patch in homebrew already, if we wanna move forward with ceres 2.0. (Would have to check if it applies cleanly on the last releases open opencv). I'll ping the rawtoaces author about ceres 2.0 compatibility. |
If |
Yeah, I have a pull request open with them since august that hasn't been looked at. So probably we should just disable it. |
26c3510
to
05941f2
Compare
da2d273
to
d438ffd
Compare
Ok, with the upstream changes in opencv no more formula changes seem to be required. Any C++14 requirements seem to be propagated by cmake for the corresponding code parts that depend on ceres. @SeekingMeaning disabled rawtoaces (there hasn't been any reaction upstream) and I squashed the commits, so I think it's ready for review. |
% brew linkage ceres-solver
System libraries:
/System/Library/Frameworks/Accelerate.framework/Versions/A/Accelerate
/usr/lib/libSystem.B.dylib
/usr/lib/libc++.1.dylib
Homebrew libraries:
/usr/local/opt/gflags/lib/libgflags.2.2.dylib (gflags)
/usr/local/opt/glog/lib/libglog.0.dylib (glog)
/usr/local/opt/metis/lib/libmetis.dylib (metis)
/usr/local/opt/openblas/lib/libopenblas.0.dylib (openblas)
/usr/local/opt/suite-sparse/lib/libamd.2.dylib (suite-sparse)
/usr/local/opt/suite-sparse/lib/libcamd.2.dylib (suite-sparse)
/usr/local/opt/suite-sparse/lib/libccolamd.2.dylib (suite-sparse)
/usr/local/opt/suite-sparse/lib/libcholmod.3.dylib (suite-sparse)
/usr/local/opt/suite-sparse/lib/libcolamd.2.dylib (suite-sparse)
/usr/local/opt/suite-sparse/lib/libcxsparse.3.dylib (suite-sparse)
/usr/local/opt/suite-sparse/lib/libspqr.2.dylib (suite-sparse)
/usr/local/opt/suite-sparse/lib/libsuitesparseconfig.5.dylib (suite-sparse)
/usr/local/opt/tbb/lib/libtbb.dylib (tbb)
Indirect dependencies with linkage:
metis
openblas
tbb
Dependencies with no linkage:
eigen |
d438ffd
to
1468255
Compare
|
1468255
to
3b67eb7
Compare
@SeekingMeaning: Oh, sorry, I didn't realize you wanted the commits split by file. Thanks for fixing it.
TBB was a direct dependency in ceres 1.14, but they removed support for it and now it is only polled in b/c it may be used indirectly by suite-sparse. The |
Yes, sorry for the misunderstanding—my comment was meant more for record-keeping (so we can refer back to this PR and see why this specific change was made) |
🤖 A scheduled task has triggered a merge. |
Created with
brew bump-formula-pr
.