Fix Qt on macOS

[dlech]

This is an attempt to fix #290.

Unfortunately, I am not able to successfully build locally so I haven't been able to fully test it. I can build a wheel, but it crashes with a segmentation fault even without this change. Hopefully there is a way to get the wheel that is built from the CI here so we can actually test it.

[dlech]

The ways this works is that the opencv cmake file is patched to copy the Qt plugins to the cmake-install directory. This seemed like the easiest way to get the correct path to the Qt install.

Then setup.py is modified to copy one of the plugins (platforms/libqcocoa.dylib) to the python package.

delocate will modify the plugin to relocate the linked libraries just as it does the cv2.so file.

Finally, the cv2.__init__.py file is modified to set the environment variable to find the plugins in the python package since the path is different from the default one that is hard-coded in Qt at compile time.

[skvark]

Sorry for having kept you waiting. I think that the changes are ok.

I just implemented a solution for persisting the build artifacts to Azure Storage. The changes are in the master branch. So if you merge those changes to this branch the artifacts should appear to Azure (I'm still waiting for Travis output for macOS builds). Some instructions for downloading them:

1. See the build log output, there should be something like this in the end:

[
  {
    "Blob": "https://[secure].blob.core.windows.net/2fd09dc0c3872f496d4c294b20de7c35ef75c39b/opencv_python-4.2.0+2fd09dc-cp35-cp35m-manylinux1_x86_64.whl",
    "Last Modified": "2020-03-21T15:39:55+00:00",
    "Type": null,
    "eTag": "\"0x8D7CDAE1AFDA647\""
  }
]

2. Replace the [secure] part in the link with opencvpythonartifacts
   • the link structure is https://opencvpythonartifacts.blob.core.windows.net/[build_commit_hash]/wheel_file_name.whl
3. Download the artifact for example via a browser

I will monitor the storage usage. I'll keep the artifacts in Azure for now since the costs are negligible for this amount of data.

[skvark]

Travis has had some issues with the builds today as well as with the Github integration (this is maybe related https://twitter.com/travisci/status/1241411541150433281), but it seems that the changes triggered a new build successfully (Github UI doesn't show the Travis link for some reason): https://travis-ci.org/github/skvark/opencv-python/builds/665299104

[dlech]

FYI, it looks like the build errored (doesn't look like it even started). Maybe try it again tomorrow.

[skvark]

Yeah, I restarted it now. I'll try again tomorrow if it does not start.

[dlech]

Some builds are working now, but there is a problem with the uploads

https://travis-ci.org/github/skvark/opencv-python/jobs/665299116#L5553-L5562

Missing credentials to access storage service. The following variations are accepted:
    (1) account name and key (--account-name and --account-key options or
        set AZURE_STORAGE_ACCOUNT and AZURE_STORAGE_KEY environment variables)
    (2) account name and SAS token (--sas-token option used with either the --account-name
        option or AZURE_STORAGE_ACCOUNT environment variable)
    (3) account name (--account-name option or AZURE_STORAGE_ACCOUNT environment variable;
        this will make calls to query for a storage account key using login credentials)
    (4) connection string (--connection-string option or
        set AZURE_STORAGE_CONNECTION_STRING environment variable); some shells will require
        quoting to preserve literal character interpretation.

[skvark]

Ah.. secure variables cannot be used in PRs due to security reasons. travis-ci/travis-ci#5579

I could just merge the changes to master and then you would be able to download and test the wheels.

[skvark]

I'll go ahead and merge this since the dylib is copied successfully to the package and all we need to do is to confirm that it's being found by Qt. If there are issues, you can create a new PR to address them.

[skvark]

Builds: https://travis-ci.org/github/skvark/opencv-python/builds/665440881

[skvark]

I have no idea what's wrong with the Python 3.7 macOS environment (Cmake doesn't seem to be able find the Python libaries for some reason), but other macOS wheels should be available for testing.

[dlech]

I tested the Python 3.6 version and was able to get a UI window, so it seems ok so far.

[dlech]

On python 3.7, I found the following error message in the logs:

-- Could NOT find PythonLibs: Found unsuitable version "3.7.7", but required is exact version "3.7.6" (found /usr/local/Frameworks/Python.framework/Versions/3.7/lib/libpython3.7m.dylib)

[dlech]

It looks like the 3.7.6 version comes from the multibuild submodule.

[dlech]

Made a pull request for this https://github.com/matthew-brett/multibuild/pull/324

[skvark]

Nice find, that explains the issue.

[skvark]

https://travis-ci.org/github/skvark/opencv-python/builds/666367918 Wheels for 3.7 should be available soon.