Modernize CMake to CMake3

[Ryanf55]

Purpose

Create an example of moving some CMake support to the latest supported features, including exported namespace targets.

In CMake 5, I propose removing the CMake 2 support because pretty much every OS now includes CMake 3. There is a lot of edge-case code to handle old versions of CMake. How much of this can be removed for OpenCV 5? Note that different versions of CMake can be required to either build or consume CMake. I've typically seen the build requirement version as usually newer version than the consume version requirement. Please help me identify what OpenCV 5 will require for building, and require for consuming. For example, build could be set at CMake 3.16 in line with the most current LTS release of Ubuntu of CMake. To consume, the generated scripts usually imply 2.8 to consume.

This is a draft, the intent is to gather feedback on what OpenCV 5 should do for the next release to make it easier/more robust to use in CMake. and easier to maintain the internal implementation.

Other improvements

The other main improvements are

• Configurable namespace for all targets
• Use CMakePackageConfigHelpers for creating config and version files for use in other projects - these didn't exist, but are recommended for use.
• The change to namespace targets is done with backwards compatibility with the existing un-namespaced targets by creating two exports, one for each type. To make use of the un-namespaced targets, consumers must enable OPENCV_EXPOSE_LEGACY_TARGET_NAMES
• I propose deprecating all the OpenCV_LIBS and other module-style variables and instead recommend users link to OpenCV targets, which express all their properties through target properties.

Related Issue

• https://github.com/opencv/opencv/issues/13117

Pull Request Readiness Checklist

See details at https://github.com/opencv/opencv/wiki/How_to_contribute#making-a-good-pull-request

• [ ] I agree to contribute to the project under Apache 2 License.
• [ ] To the best of my knowledge, the proposed patch is not based on a code under GPL or another license that is incompatible with OpenCV
• [ ] The PR is proposed to the proper branch
• [ ] There is a reference to the original bug report and related work
• [ ] There is accuracy test, performance test and test data in opencv_extra repository, if applicable Patch to opencv_extra has the same branch name.
• [ ] The feature is well documented and sample code can be built with the project CMake

[opencv-alalek]

if we respect OpenCV users then there should a timeframe for transition to avoid unwanted breaking of user code on OpenCV version upgrades.

• 4.x: without regressions in default builds provide cmake3 features (if some conflicts provide them under some flag - disabled by default). This would allow testing and migration on new features on user side.
• provide transition guidelines
• deprecate old features and emit warning with the link on transition guidelines
• in 5.0 switch flags of new features to ON, but keep old functionality if user specify these features OFF.
• in 5.x/6.0 remove old functionality

[Ryanf55]

if we respect OpenCV users then there should a timeframe for transition to avoid unwanted breaking of user code on OpenCV version upgrades.

• 4.x: without regressions in default builds provide cmake3 features (if some conflicts provide them under some flag - disabled by default). This would allow testing and migration on new features on user side.
• provide transition guidelines
• deprecate old features and emit warning with the link on transition guidelines
• in 5.0 switch flags of new features to ON, but keep old functionality if user specify these features OFF.
• in 5.x/6.0 remove old functionality

I agree with all of these. The defaults for this PR scan be adjusted if we want to backport anything to 4.x. My impression was that an upgrade of the minimum required version of CMake to build on 4.x would not be allowed. If that's true, not much can change on 4.x. Much of this PR is centered on capabilities that are only available in CMake 3.5.

[Ryanf55]

Is there any more feedback from the OpenCV team? Is there any desire to improve the CMake user experience for OpenCV5?

[FantasqueX]

Great work! Just a notice, if we bump cmake_minimum_required, we can use several new policy like CMP0148 and CMP0146.