mlt: migrate to opencv3

[mascguy]

Description

Migrate mlt from opencv, to opencv3

Specifically tested both the default install, as well as variant +opencv. For the latter, verified that opencv3 is being properly found during configure phase, and that binaries are linking to opencv3 shared libs.

Type(s)

• bugfix
• enhancement
• security fix

Tested on

macOS 10.12.6 16G2136
Xcode 9.2 9C40b

macOS 10.13.6 17G14019
Xcode 10.1 10B61

macOS 10.14.6 18G103
Xcode 11.3.1 11C505

macOS 10.15.6 19G2021
Xcode 12.0 12A7209

Verification

Have you

• followed our Commit Message Guidelines?
• squashed and minimized your commits?
• checked that there aren't other open pull requests for the same change?
• referenced existing tickets on Trac with full URL?
• checked your Portfile with port lint?
• tried existing tests with sudo port test?
• tried a full install with sudo port -vst install?
• tested basic functionality of all binary files?

[macportsbot]

Notifying maintainers:
@RJVB for port mlt.
@ddennedy for port mlt.

[RJVB]

Are there implications for the OS versions supported?

[mascguy]

Are there implications for the OS versions supported?

Well, port opencv3 is essentially the same as opencv. Even the versions are identical. (Both are at 3.4.14.) The only difference between the two, is that opencv3 cleanly isolates everything - including the headers and libs - so that there's no conflict with opencv4. (And that isolation also allows us to create a legacy opencv2 port, which has been requested by users. That's coming eventually, when I get around to it.)

Otherwise, whatever MacOS releases are supported by opencv, are supported by opencv3. This is truly a drop-in change, that doesn't affect anything other than where the OpenCV shared libs are loaded from.

Does that make sense?

[RJVB]

On Saturday April 24 2021 11:12:30 Christopher Nielsen wrote: Does that make sense?

Yes, and in that case I have no objections either.

[RJVB]

So out of curiosity, what's the future for port:opencv? Shouldn't it declare itself replaced-by port:opencv3, or become a shim that depends on port:opencv3 and just installs the `libopencv*.3.dylib` symlinks into ${prefix}/lib to keep existing dependencies happy and working? (Actually, at first glance it looks like `port:opencvX` could install `libopencv*.X.dylib` symlinks there to avoid the need for a revbump. Opencv dependents can be huge enough that you don't want to have to rebuild them for "cosmetics", if my private digiKam port is any indication!)

[cjones051073]

I would say once all uses of if have been migrated to opencv{3,4} it should then just be obsoleted. opencv3 is 'almost' a direct replacement, as although it provides the same the files are at different locations which require specific configurations to use.

[RJVB]

I would expect that the exact install location is irrelevant at runtime as long as the dependents find the dylibs they require, be it directly, through a symlink or because of DYLD_LIBRARY_PATH. If that's indeed the case you would evidently still have to change their portfiles so that rebuilds find everything in the proper new place but you wouldn't have to do a revbump.

[mascguy]

Agreed, the plan is to obsolete opencv, with a replaced_by opencv3.

[mascguy]

So out of curiosity, what's the future for port:opencv? Shouldn't it declare itself replaced-by port:opencv3, or become a shim that depends on port:opencv3 and just installs the libopencv*.3.dylib symlinks into ${prefix}/lib to keep existing dependencies happy and working? (Actually, at first glance it looks like port:opencvX could install libopencv*.X.dylib symlinks there to avoid the need for a revbump. Opencv dependents can be huge enough that you don't want to have to rebuild them for "cosmetics", if my private digiKam port is any indication!)

Well, we specifically don't want OpenCV-related headers and libraries to be found in the standard locations like ${prefix}/include and ${prefix}/lib, as that is problematic when supporting multiple versions side-by-side. (Indeed, we now support installation of OpenCV 3 and 4 simultaneously, and OpenCV 2 is coming eventually due to user request.)

So we pushed OpenCV headers and libs down a level, into ${prefix}/include/opencvX and ${prefix}/lib/opencvX. We also segregated the CMake files and pkgconfig file, to ensure ports don't inadvertently find the "wrong" version. (OpenCV 4's pkgconfig was recently stuffed back into ${prefix}/lib/pkgconfig, but I plan to fix that soon... today, if possible.)

In any case, it's all about segregation, to avoid any possible conflicts/issues. Does that make sense?

[mascguy]

Oh, and digikam has been problematic, in terms of migrating off of opencv: Builds fail across-the-board, for every MacOS release. Making it very difficult to test. LOL

Just curious, did you make changes to get it to build successfully? Please share your secrets! ;-)

[RJVB]

In any case, it's all about segregation, to avoid any possible conflicts/issues. Does that make sense?

Sure, I understand the purpose of segregation (and regret it's not foreseen by upstream themselves, apparently).

Oh, and `digikam` has been problematic, in terms of migrating off of `opencv`: Builds fail across-the-board, for every MacOS release. Making it very difficult to test. LOL Just curious, did you make changes to get it to build successfully? Please share your secrets! ;-)

My digiKam port is currently at 7.1.0 , it's been a long time since I looked at digiKam4!

[cjones051073]

My digiKam port is currently at 7.1.0 , it's been a long time since I looked at digiKam4!

maybe you could submit a PR updating it, if its that out of date.. ?

[mascguy]

My digiKam port is currently at 7.1.0 , it's been a long time since I looked at digiKam4!

maybe you could submit a PR updating it, if its that out of date.. ?

I second that idea!

[mascguy]

Created a new ticket, covering the Digikam update (CCing you both):

62755 - digikam: update to 7.2.0

[RJVB]

maybe you could submit a PR updating it, if its that out of date.. ?

See my reply on the ticket. I was never going to introduce my ports through an endless series of PRs, in any case.

[RJVB]

Oh, and `digikam` has been problematic, in terms of migrating off of `opencv`: Builds fail across-the-board, for every MacOS release. Making it very difficult to test. LOL

Is it just digiKam or is OpenCV actually designed rather poorly in its versioning? You'd expect that apps depending on libopencv_dnn.3.4.dylib would "survive" the update from OpenCV 3.4.4 to 3.4.14 but instead they require a rebuild. IOW, the *.3.4.dylib symlinks should be removed so that it becomes possible (for those who want) to keep older libopencv_foo.3.4.X libraries installed for the benefit of dependents you don't want (or cannot) rebuild immediately. A thought for upstream, evidently.

[mascguy]

Oh, and digikam has been problematic, in terms of migrating off of opencv: Builds fail across-the-board, for every MacOS release. Making it very difficult to test. LOL
Is it just digiKam or is OpenCV actually designed rather poorly in its versioning? You'd expect that apps depending on libopencv_dnn.3.4.dylib would "survive" the update from OpenCV 3.4.4 to 3.4.14 but instead they require a rebuild. IOW, the *.3.4.dylib symlinks should be removed so that it becomes possible (for those who want) to keep older libopencv_foo.3.4.X libraries installed for the benefit of dependents you don't want (or cannot) rebuild immediately. A thought for upstream, evidently.

Generally, dependent ports are linked to the major.minor version of the dylibs, like libopencv_core.3.4.dylib. So the case you mention, updating from 3.4.4 to 3.4.14, won't break dependents. Ideally, though, we'd link to libopencv_core.dylib, so that we never break dependents. (Not just for this case, but all across MacPorts.)

As for Digikam, since I can't run a successful build, it's impossible to truly validate that any portfile changes work properly. That's also true for another port (orfeotoolbox), which is also failing to build across-the-board. Ticket: orfeotoolbox 4.0.0: builds failing across-the-board

I could use some thoughts/direction on how to deal with this situation, as we'd really like to eliminate the last remaining dependencies on port opencv. How would you folks handle this?

[RJVB]

Generally, dependent ports are linked to the major.minor version of the dylibs, like `libopencv_core.3.4.dylib`. So the case you mention, updating from 3.4.4 to 3.4.14, won't break dependents

I know that this is how it should be, but I can assure you that 3.4.14 doesn't have `_ZN2cv3dnn22experimental_dnn_34_v73Net7forwardERKNS_12_OutputArrayERKSt6vectorINS_6StringESaIS7_EE` (aka `cv::dnn::experimental_dnn_34_v7::Net::forward(cv::_OutputArray const&, std::vector<cv::String, std::allocator<cv::String> > const&)`). Instead, it has `_ZN2cv3dnn23experimental_dnn_34_v213Net7forwardERKNS_12_OutputArrayERKSt6vectorINS_6StringESaIS7_EE (aka `cv::dnn::experimental_dnn_34_v21::Net::forward(cv::_OutputArray const&, std::vector<cv::String, std::allocator<cv::String> > const&)` Admittedly I ran onto this on Linux but I have no reason to expect that a Mac build will NOT have these kind of versioned symbols.

Ideally, though, we'd link to `libopencv_core.dylib`, so that we never break dependents.

Yes, that's the linker/interface library, but not the one that gets recorded in the dependency list.