ceres-solver 2.0.0

[NikolausDemmel]

Created with brew bump-formula-pr.

[dtrodrigues]

opencv, opencv@3, and rawtoaces need revision bumps.

Should cmake instead be a build-only dependency?

[NikolausDemmel]

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:

opencv, opencv@3, and rawtoaces need revision bumps.

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:

• Wait for upstream to become compatible with ceres 2.0. For opencv 3 and 4 I would guess it will never happen, b/c of C++11. I guess it will take forever until they are phased out. For rawtoaces we would have to see (didn't investigate yet if someone raised this upstream with rawtoaces yet).
• Remove the formula dependencies, in particular from the opencv formulas. In the current release it's only an optional dependency of the sfm contrib (and a known issue w.r.t. ceres 2.0). Not sure how many would be affected by not having these optional parts of the sfm contrib available from the opencv formula. Moreover, it looks like ceres recently got added additionally as a dependency to the rgbd contrib, but w.r.t. to this issue they said that the best "fix" would be to remove the ceres dependency alltogether from the rgbd contrib.
• Introduce a versioned formula ceres-solver@1, but after reading the documentation on that, I'm not sure if it qualifies in terms of popularity stats. Moreover, I don't think the ceres maintainers have plans to maintain the 1.14 branch separately (but version 1.14. was released in March 2018, so it has been stable for a long time).

Any suggestions which way to go here?

Should cmake instead be a build-only dependency?

I think so.

[jonchang]

Wait for upstream to become compatible with ceres 2.0. For opencv 3 and 4 I would guess it will never happen, b/c of C++11. I guess it will take forever until they are phased out.

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.

[alalek]

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).

[alalek]

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)

[NikolausDemmel]

Yeah, makes sense, thanks. With your upstream changes in opencv I probably don't have to change anything about the formula here.

[BrewTestBot]

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.

[NikolausDemmel]

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.

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.

Update: AcademySoftwareFoundation/rawtoaces#121

[SeekingMeaning]

If rawtoaces still isn't compatible when the new opencv releases come out, I think we should disable (or deprecate) it with :does_not_build as the reason. The latest (and only) release was released 3 years ago, and there hasn't been much activity in the GitHub repository other than two PR merges that modified their README.

[jonchang]

Yeah, I have a pull request open with them since august that hasn't been looked at. So probably we should just disable it.

[SeekingMeaning]

opencv - #67482
opencv@3 - #67515

[NikolausDemmel]

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.

[SeekingMeaning]

% 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

[SeekingMeaning]

-DTBB=OFF was added in 7f34377 to avoid opportunistic linkage, and suite-sparse at the time did not depend on tbb (This is no longer the case as of 5195792)

[NikolausDemmel]

@SeekingMeaning: Oh, sorry, I didn't realize you wanted the commits split by file. Thanks for fixing it.

-DTBB=OFF was added in 7f34377 to avoid opportunistic linkage, and suite-sparse at the time did not depend on tbb (This is no longer the case as of 5195792)

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 TBB cmake argument was removed in ceres.

http://ceres-solver.org/installation.html

[SeekingMeaning]

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)

[BrewTestBot]

🤖 A scheduled task has triggered a merge.