[ceres] Should not set CMAKE_CXX_STANDARD

[reynoldsbd]

---

Description of problem

The portfile for Ceres contains the following logic:

vcpkg/ports/ceres/portfile.cmake

Lines 60 to 65 in 7e7dad5

	file(READ ${CURRENT_PACKAGES_DIR}/share/ceres/CeresConfig.cmake CERES_CONFIG)
	string(REPLACE "set_target_properties(ceres PROPERTIES INTERFACE_LINK_LIBRARIES Ceres::ceres)"
	"set_target_properties(ceres PROPERTIES INTERFACE_LINK_LIBRARIES Ceres::ceres)
	set(CMAKE_CXX_STANDARD 14)
	set(CMAKE_CXX_STANDARD_REQUIRED ON)" CERES_CONFIG "${CERES_CONFIG}")
	file(WRITE ${CURRENT_PACKAGES_DIR}/share/ceres/CeresConfig.cmake "${CERES_CONFIG}")

This can create issues for users who import Ceres into their projects using find_package(Ceres), because this unconditionally and globally overwrites the CMAKE_CXX_STANDARD variable to the value 14. As a result, consumers who wish to use a different C++ standard are forced to manually (re)set this variable after including Ceres.

This behavior appears to have been introduced here, as part of #12785.

Proposed solution

Modify the Ceres portfile to stop injecting these lines. vcpkg should not modify the user's CMAKE_CXX_STANDARD variable. Provided there is agreement, I am happy to submit such a PR.

Note that the upstream Ceres project already enforces a minimum C++ standard using a more idiomatic and targeted CMake mechanism.

Describe alternatives you've considered

I am currently able to work around this issue by manually resetting CMAKE_CXX_STANDARD after including Ceres:

set(orig_cxx_std ${CMAKE_CXX_STANDARD})
find_package(Ceres REQUIRED)
set(CMAKE_CXX_STANDARD ${orig_cxx_std})

Additional context

This behavior appears to have been introduced by #12785. cc @cenit, @JackBoosY, @BillyONeal

[BillyONeal]

Timeline:

• 2018-03-29 The linked change was made in ceres: ceres-solver/ceres-solver@282b8b5
• 2020-03-25 Ceres 1.14.x added to vcpkg: afe6d4f#diff-16c32e1ebb4f18f123aaeef3ab97b2b8d3293acec6d2c5c8c48166ab8ff1063e

This means that whatever problem #14719 was trying to fix seems to not be able to use that for some reason.

• 2020-05-30 Upstream minimum C++ changed to 14: ceres-solver/ceres-solver@7ef83e0#diff-a3b92e34b93c0cca1d994e6782bfbd21f40d3264a75d1b6ff9247f1d82864791
• 2020-12-01 Ceres 2.0.0 added to vcpkg [ceres] upgrade to 2.0.0 #14719
• 2020-12-11 That find/replace introduced [OpenCV] fix compatibility with VTK9 #12785

@cenit Can you comment as to why that specific change was made?

[BillyONeal]

I observe that the target_compile_options upstream is trying to do does not make it into the exported targets because they set cmake_minimum_required(VERSION 3.5) but the ability to do that seems to have been added in 3.8 or 3.11: https://cmake.org/cmake/help/latest/command/target_compile_options.html#arguments

[BillyONeal]

Hmmm nvm I missed that I guess. The target_compile_features is present in both.

[cenit]

Timeline:

• 2018-03-29 The linked change was made in ceres: ceres-solver/ceres-solver@282b8b5
• 2020-03-25 Ceres 1.14.x added to vcpkg: afe6d4f#diff-16c32e1ebb4f18f123aaeef3ab97b2b8d3293acec6d2c5c8c48166ab8ff1063e

This means that whatever problem #14719 was trying to fix seems to not be able to use that for some reason.

• 2020-05-30 Upstream minimum C++ changed to 14: ceres-solver/ceres-solver@7ef83e0#diff-a3b92e34b93c0cca1d994e6782bfbd21f40d3264a75d1b6ff9247f1d82864791
• 2020-12-01 Ceres 2.0.0 added to vcpkg [ceres] upgrade to 2.0.0 #14719
• 2020-12-11 That find/replace introduced [OpenCV] fix compatibility with VTK9 #12785

@cenit Can you comment as to why that specific change was made?

i think that the target_compile_options were not present at the time of my #12785 PR in that current ceres version, and upgrade to v2 in #14719 didn't remove the "quick and dirty" patch that was forcing c++14 on a downstream project

[BillyONeal]

i think that the target_compile_options were not present at the time of my #12785 PR in that current ceres version, and upgrade to v2 in #14719 didn't remove the "quick and dirty" patch that was forcing c++14 on a downstream project

I think it was in there, because it was done in 2018 but the version we were using when your changes were made was in 2020. I'm worried about accidentally dropping what you were doing on the floor. If you don't remember what it was and CI is passing, I'm just going to go with it?

[cenit]

d66679f

the commit i did says that it was necessary for downstream ports using classic target and not the namespaced one. And that is coherent with the position inside the config file.

With vcpkg-ci-opencv not tested in many configs, the vtk module that required it is not tested too, and so i am not sure about the ci green reliability...

[BillyONeal]

the commit i did says that it was necessary for downstream ports using classic target and not the namespaced one. And that is coherent with the position inside the config file.

That's strange to me since the classic target should be doing target_link_libraries (effectively) to the namespaced one.

[BillyONeal]

With vcpkg-ci-opencv not tested in many configs, the vtk module that required it is not tested too, and so i am not sure about the ci green reliability...

What ports would you like me to manually test?

I know of:

• vcpkg-ci-opencv:ALL_THE_TRIPLETS ?