[ceres + downstreams] Update to ceres to 2.2.0#42475
[ceres + downstreams] Update to ceres to 2.2.0#42475JavierMatosD merged 70 commits intomicrosoft:masterfrom
Conversation
|
@microsoft-github-policy-service agree |
|
Build failures appear to be unrelated to this change? |
They look legitimate to me? A couple of examples: Direct failures: Indirect failures, for instance: are downstream broken components: PS D:\vcpkg> .\vcpkg.exe depend-info cartographer 2>&1 | findstr ceres
ceres[lapack, suitesparse]: eigen3, glog, lapack, suitesparse, vcpkg-cmake, vcpkg-cmake-config
cartographer: boost-iostreams, cairo, ceres, gflags, glog, gtest, lua, protobuf, vcpkg-cmake, vcpkg-cmake-config
PS D:\vcpkg> .\vcpkg.exe depend-info openturns 2>&1 | findstr ceres
ceres: eigen3, glog, vcpkg-cmake, vcpkg-cmake-config
openturns: blas, boost-multiprecision, boost-random, ceres, cminpack, dlib, exprtk, hdf5, lapack, libxml2, mpc, mpfr, muparser, nlopt, pagmo2, pthread, python3, spectra, tbb, vcpkg-cmake, vcpkg-cmake-config
PS D:\vcpkg> .\vcpkg.exe depend-info openmvg 2>&1 | findstr ceres
ceres[cxsparse, lapack, suitesparse]: eigen3, glog, lapack, suitesparse, vcpkg-cmake, vcpkg-cmake-config
openmvg: cereal, ceres, coin-or-clp, coin-or-osi, coinutils, eigen3, flann, libjpeg-turbo, liblemon, libpng, tiff, vcpkg-cmake, vcpkg-cmake-config, vlfeat, zlib
PS D:\vcpkg> |
I guess, what I mean is, I don't think we should have accepted a 1500 line patch in the first place. That's well outside of our normal patch guidelines, and it's unwarranted if there is no universe where upstream could someday accept it.
Yes, those are the two in question here. @AugP @ras0219-msft @JavierMatosD @vicroms and I discussed today and agree these should be removed from the index. I'll push that into this PR shortly. |
… patches to adapt to updated ceres versions, and are unmaintained by upstreams.
I deindexed cartographer entirely and have an action item to update the maintainer guide about these cases where large patches are necessary to get unmaintained downstream dependents functional. Do you have other concerns here @JonLiu1993 ? @ahojnnes Are you happy with this 'the ports got deindexed' outcome? |
|
Tested usage successfully by
|
Co-authored-by: Kai Pastor <dg0yt@darc.de>
Thank you, sounds good to me! |
|
Looks there is a error in x64-linux, this is error log: |
|
@JonLiu1993 Shouldn't have removed the openmvg:x64-linux from the ci exclusions :-) I'll see if I can fix it, but otherwise will revert back to the previous state and skip it. |
f4e9c34 to
4301643
Compare
|
@JonLiu1993 @BillyONeal All checks should be green now. Thank you for your reviews and support. |
JavierMatosD
left a comment
There was a problem hiding this comment.
LGTM, please fix the file conflicts
| # search should be for an exact match, but for usability reasons do a soft | ||
| # match and reject with an explanation below. | ||
| -find_package(Eigen3 ${CERES_EIGEN_VERSION} QUIET) | ||
| +find_package(Eigen3 CONFIG ${CERES_EIGEN_VERSION} QUIET) |
There was a problem hiding this comment.
find_package calls should never be QUIET in vcpkg
There was a problem hiding this comment.
If you look at the next few lines in the original config file, you will find that it is not really quiet but it fails if the find_package call was unsuccessful. It has some custom logic that alters internal variables. I suggest keeping the patch minimal, as the behavior will be the same.
…/jsch/ceres-2.2.0
|
@JavierMatosD @BillyONeal @JonLiu1993 I'd appreciate if we could merge this update, so I don't run into further merge conflicts. Thank you. |
|
That is amazing, thank you very much @ahojnnes for the work! |
./vcpkg x-add-version --alland committing the result.