Create Mac Studio app package

[w-m]

• adapt make_dmg_functions.sh to work with MacPorts binaries (rpath?)
• adapt make_dmg_functions.sh to work with HomeBrew binaries (rpath?)
• disable codesign (stitchEm is not eligible for to get the membership fees of the Apple Developer Program waived)
• create library license page
• create menu / help entry linking to license page
• create release on GitHub, upload .dmg
• automatically push .dmg to GitHub from Travis?

[w-m]

We may be able to use https://github.com/auriamg/macdylibbundler to do all the install_name_tool grunt work

[w-m]

Oh actually the current packaging code works fine in doing all necessary steps, no matter where the binaries come from, tried with MacPorts. I thought it required them to be already rpath'ed, but it doesn't.

[w-m]

Note to self: don't forget "-DBUILD_MACOSX_BUNDLE=ON" when configuring. Also make sure to set Qt version in the file qt.version to the same version as used in the CMAKE config.

I've got a working package locally. Issues:

• doesn't launch, gives a CUDA error on a Nvidia-only machine. required me to re-link libvs to libvs_cuda, then it launches
• additional libvs.dylibs in Contents/MacOS (should only be in Contents/Frameworks)
• no app icon
• non-sensical .webloc in the installer
• doesn't have a proper version

There's > 120 libs now in Contents/Frameworks, compared to ~40 in VideoStitch Studio 2.3. Probably due to lots of features in ffmpeg/OpenCV/Eigen that are built in the MacPorts version that we disabled for VS deps.

[w-m]

doesn't launch, gives a CUDA error on a Nvidia-only machine. required me to re-link libvs to libvs_cuda, then it launches

make_dmg_functions.sh throws ERROR: Cannot resolve rpath "CUDA.framework/Versions/A/CUDA".

For some reason, /usr/local/cuda/lib/libcuda.dylib links to @rpath/CUDA.framework/Versions/A/CUDA. Why is this @rpath, and not just /Library/Frameworks/..., where the CUDA framework actually sits?

https://stackoverflow.com/questions/44714830/osx-sierra-tensorflow-build-error-ld-file-not-found-rpath-cuda-framework-ver suggests to manually change that link with install_name_tool. For some reason this is not enough, and the error message in make_studio_dmg persists. libvideostitch_cuda.dylib still has the rpath enty, where does this come from?

A dmg and package produced with this will still launch when the binary is directly called from the command line. It will not launch (showing "Your CUDA driver appears to be outdated"?!) when the app package is opened. Difference when looking at opened files: the command-line version opens /usr/local/cuda/lib/libcuda.dylib, the app package one does not.

(Once launched from the command line, the symlink is changed to _cuda, and then the app package launches as well).

[w-m]

Current work on https://github.com/stitchEm/stitchEm/tree/w-m/mac-package

[w-m]

Hm, libvideostitch.dylib in VideoStitch Studio 2.2.1 also linked to @rpath/CUDA.framework/Versions/A/CUDA, this does not seem to be the source of the issue.

[w-m]

doesn't have a proper version

fixed an issue in the regex that slashes aren't supported in branch names

[w-m]

Dual-backend-builds are assumed broken, and won't be fixed. We will just release single-backend builds. The UI/warning implications for that are in #37.

The las open point, the automatic builds are in discussed in #71.

[jeremad]

If you provide me the command to build the installed I can implement that!