cmake: Modernize (and fix) deployment on macOS For the past decade or so, we have used a bunch of self-written python and bash scripts for creating packages for macOS. These have not aged well, and recently several workarounds had to be hacked in to keep the machinery somewhat working at all. Still, invoking the scripts at build time rather than install time caused a race condition where sometimes not all the packages would be created in CI. To break the camel's back, deploying dependencies no longer worked correctly and broke the packages completely in 0.14-rc1. Fix this by modernizing the whole deployment process and related parts of the build system, replacing the custom scripts by relying on Qt's and CMake's own tooling instead. Some workarounds still need to be added to that to make everything work correctly (neither tool can deal correctly with QtWebEngine, for some reason, and CMake's Info.plist template lacks functionality), but the main part of the work is now delegated to official tooling, everything properly happend at install time avoiding race conditions in the build process, and we can remove a bunch of decade-old and hardly maintained custom code. Also adapt the CI configuration to use -DBUNDLE instead of the old -DDEPLOY, and remove the explicit setting of qmake's path too, as it is no longer needed now.
build: Set macOS minimum version to Qt min version Set the macOS Info.plist minimum version to the minimum version supported by Qt for macOS. Determine the minimum macOS version for Qt through querying qmake. Unfortunately, this involves a somewhat roundabout process of a fake project file and searching qmake's output. See https://code.qt.io/cgit/pyside/pyside-setup.git/tree/qtinfo.py?h=5.6 Switch to HFS+ (from APFS) so older macOS versions can parse the app bundle and display the "OS version too old" warning, instead of just warning about a corrupt image file. Credit to freenode/Deas for point this out and providing screenshots! See https://doc.qt.io/qt-5/macos.html And https://doc.qt.io/qt-5/macos-deployment.html
ci: Workaround macOS hdiutil out of space errors Workaround "hdiutil: create failed - No space left on device" by letting hdiutil auto-detect the required disk space. Keep the old method around via documentation in case this issue arises again. https://stackoverflow.com/questions/18621467/error-creating-disk-image-using-hdutil https://apple.stackexchange.com/questions/156994/yosemite-hdiutil-create-failed-error-5341 https://asmaloney.com/2013/07/howto/packaging-a-mac-os-x-application-using-a-dmg/ https://github.com/autopkg/jps3-recipes/issues/57 Make this issue easier to detect by changing the build script macosx_makePackage.sh to fail early if any individual command fails. This includes fixing up optional parameters to use default values. Re-enable the "Check artifacts" step of the "Post-Build" process now that macOS builds are hopefully more reliable.
Use craft on appveyor This will use the well maintained packages from Craft. It will reduce the maintenance cost for providing a Windows installer. Additionally we now use up to date binaries built exactly for this compiler, so we no longer depend on 33dparty openssl binaries etc. Using and deploying KDE Framework 5 libaries on Windows is also possible now. This build provides KDE Sonnet Find out more about Craft: https://community.kde.org/Craft Contribute to the Quassel blueprint: https://github.com/KDE/craft-blueprints-kde/blob/master/qt-apps/quassel/quassel.py Closes GH-312.
Retry Chocolatey install to workaround failures Automatically retry up to 3 times on failure when installing Chocolatey modules, using the 'appveyor-retry' script. This can be removed later if needed. Sometimes Chocolatey returns a 404 for a package that exists. This happens a lot. The official fix is to get the Business edition for the more-stable private CDN, but since we're an open-source community effort, sometimes a little kludgery goes a long way. See http://help.appveyor.com/discussions/suggestions/816-generic-wrapper-for-retry#comment_40579488 And https://github.com/appveyor/ci/issues/418