Use 2.4 vcpkg branch for MacOS and Windows

[daschuer]

This PR does the switch and makes it work for macOS and windows.

[Be-ing]

Thank you very much for working on this. I will review it soon.

[coveralls]

Pull Request Test Coverage Report for Build 1159589324

• 0 of 0 changed or added relevant lines in 0 files are covered.
• 3 unchanged lines in 2 files lost coverage.
• Overall coverage decreased (-0.004%) to 25.964%

---

Files with Coverage Reduction	New Missed Lines	%
src/engine/enginevumeter.cpp	1	90.24%
src/engine/cachingreader/cachingreaderworker.cpp	2	63.48%

Totals
Change from base Build 1154301022:	-0.004%
Covered Lines:	20007
Relevant Lines:	77057

---

💛 - Coveralls

[Be-ing]

-- Could NOT find DjInterop (missing: DjInterop_LIBRARY DjInterop_INCLUDE_DIR)

libdjinterop is in vcpkg now. We should add it to the build environments. But that is no regression from the old environment so we don't need to fix it in this PR.

[Be-ing]

ld: warning: direct access in function 'QMimeTypePrivate::QMimeTypePrivate(QMimeTypePrivate const&)' from file '/Users/runner/buildenv/mixxx-deps-2.4-x64-osx-0f25dfd/installed/x64-osx/lib/libQt5Core.a(qmimetype.o)' to global weak symbol 'QHash<QString, QString>::deleteNode2(QHashData::Node*)' from file 'CMakeFiles/mixxx-test.dir/src/test/midicontrollertest.cpp.o' means the weak symbol cannot be overridden at runtime. This was likely caused by different translation units being compiled with different visibility settings.

There are a lot of these linker warnings from Qt. Are they a problem?

[daschuer]

Regarding the compiler warnings I give up. We have tests, that this build is working and the warnings are IMHO not critical.
More a cosmetically issue when as far as I understand it.
So I think we can go ahead, merge this and wait for a macOS contributor who is able to remove the warnings locally.
It does not make sense for me to do the debugging via remote without the chance to test it locally.

Maybe be get a responds from my question issued here: microsoft/vcpkg#19699

[Be-ing]

I think we can leave the link warnings as a to-do card on the 2.4 project board. I want to test building this locally on macOS before merging though.

[Be-ing]

I made a PR for your branch: daschuer#68

[Be-ing]

It turns out that it was the missing MAC_OS_X_VERSION_MAX_ALLOWED definition that makes QT using 10.14 functions, when building with the 10.15 SDK.

I have not reproduced this link error locally.

[Be-ing]

Undefined symbols for architecture x86_64:
  "_NSAppearanceNameDarkAqua", referenced from:
      qt_mac_applicationIsInDarkMode() in libQt5Core.a(qcore_mac_objc.o)
  "_SSLCopyALPNProtocols", referenced from:
      QSslSocketBackendPrivate::continueHandshake() in libQt5Network.a(qsslsocket_mac.o)
  "_SSLSetALPNProtocols", referenced from:
      QSslSocketBackendPrivate::initSslContext() in libQt5Network.a(qsslsocket_mac.o)

This link error did not occur on my PR for your branch.

[daschuer]

It should occur, because NSAppearanceNameDarkAqua is only available from macOS 10.14 but we wan't make Mixxx run on macOS 10.12.
So I guess there must be an issue that the Deployment target environment variable is ignored.
My wild guess is that we need it as a real environment variable where CMake inherits from.

[Be-ing]

I think all that is left is to update the vcpkg ZIP archive to the build from merging mixxxdj/vcpkg#24 then we can merge this.

[Be-ing]

My wild guess is that we need it as a real environment variable where CMake inherits from.

I don't think so. CMake uses the MACOSX_DEPLOYMENT_TARGET environment variable to set the CMAKE_OSX_DEPLOYMENT_TARGET CMake variable. So I don't think there is any functional diffrence whether one or the other is used.

[Be-ing]

Hmm, you are right. Somehow CMAKE_OSX_DEPLOYMENT_TARGET is not getting set to 10.12. If you look at the end of the Configure step in the most recent build where CMake prints all the CMake cache variables you can see
CMAKE_OSX_DEPLOYMENT_TARGET:STRING=10.15

For the build that failed it was
CMAKE_OSX_DEPLOYMENT_TARGET:STRING=10.12

[Be-ing]

Here is another PR to get CMake to actually set the deployment target to 10.12: daschuer#69

[Be-ing]

Let's merge this now and add libdjinterop to the vcpkg archive when my PR is merged upstream. I don't think that will take too long so I don't think we need to bother adding it to the overlay for this temporary issue.

[daschuer]

Do you know why we have no linker issues anymore. That is suspicious.

I have stated a new vcpkg build without caching in the 2.3.macos branch.
Let's test if this builds as well.

[Be-ing]

I do not know why the link errors occurred on that one build. But they have not happened since and I have not seen them in any of my local builds. So I am not too concerned.

[Be-ing]

I did a local build with the environment variable MACOSX_DEPLOYMENT_TARGET=10.12 to check. There were no link errors nor warnings besides this known one:

ld: warning: could not create compact unwind for _ff_cfhd_init_vlcs: stack subq instruction is too different from dwarf stack size
ld: warning: could not create compact unwind for _ff_rl_init_vlc: stack subq instruction is too different from dwarf stack size

[Be-ing]

By the way, the old Macbook Air I was using before is no longer useful for building Mixxx because its version of clang is too old to support some of the C++17 features we use. :( I tried updating it to macOS 10.13.6 which supports a newer version of XCode which I think should support C++17. It said it was updating the OS but it never actually does. :/ Thanks for making a functioning computer into trash, Apple. But now my roommate has an iMac which is quite fast (faster than GitHub Actions' macOS runners).

[daschuer]

I can confirm that this is still building with a re-build vcpkg.

It was original failing because of QT's 10.14 calls when using the 10.13 SDK

Now we are using the 11.1 SDK on a macOS 10.15 runner.

Interestingly the vcpkg is built with the "native' 10.15 SDK. I have no clue where this difference happens.

But anyway, our goal a Mixxx binary running on a macOS 10.12. @Be-ing: can you confirm this with your abandoned Macbook Air?

Please also explain how the calls to more recent calls are handled? Does Mixxx than require to update some libraries to their 11.1 version?

[daschuer]

After reading this message,
https://lists.apple.com/archives/xcode-users/2005/Aug/msg00399.html
I have finally understand how it is supposed to work.

QT checks it with

#if QT_MACOS_PLATFORM_SDK_EQUAL_OR_ABOVE(__MAC_10_14)
    if (__builtin_available(macOS 10.14, *)) {
        auto appearance = [NSApp.effectiveAppearance bestMatchFromAppearancesWithNames:
                @[ NSAppearanceNameAqua, NSAppearanceNameDarkAqua ]];
        return [appearance isEqualToString:NSAppearanceNameDarkAqua];
    }
#endif

This has failed originally, because the QT library was build statically with 10.15 where this function exists, while Mixxx uses only 10.13 (sdk download) without this function.

Since we link the function statically, it should run also on an older macOS, we have "only" the issue that this is not supported by QT

Which already warns using 10.15 but we finally use 11.1

Project WARNING: Qt has only been tested with version 10.14 of the platform SDK, you're using 10.15.
Project WARNING: This is an unsupported configuration. You may experience build issues, and by using
Project WARNING: the 10.15.6 SDK you are opting in to new features that Qt has not been prepared for.
Project WARNING: Please downgrade the SDK you use to build your app to version 10.14, or configure
Project WARNING: with CONFIG+=sdk_no_version_check when running qmake to silence this warning.

Is this and issue or not?

We need to test.

[Be-ing]

But anyway, our goal a Mixxx binary running on a macOS 10.12. @Be-ing: can you confirm this with your abandoned Macbook Air?

I tried to confirm this but unfortunately that Macbook Air is now stuck in a boot loop attempting to update macOS :(

[Be-ing]

Is this and issue or not? We need to test.

I don't think so. I have not noticed any issues with the current state of this branch nor has anyone else reported issues.

We may be able to use xcode-select to use the 10.14 SDK with the oldest XCode version available in the GitHub Actions runners, XCode 10.3. I tried this but curiously those link errors about dark mode reappeared. That might work if we built the dependencies with the 10.14 SDK too. But I don't think that is worth the trouble and it would be a fragile setup. macOS developers are not going to want to go through the trouble of downloading an old version of XCode so they can build with the same SDK we used on CI, which could create confusing differences. Also, I have no idea how long the macOS 10.15 GitHub Actions runners will remain available. The macOS 11 runners do not have XCode 10.3. The only reason we are still using the macOS 10.15 runners is because the macOS 11 runners took a while to start jobs when they first became available (there was also the issue of PortAudio not working when built with the macOS 11 SDK but that has since been fixed).

So I think we should stop messing with it and merge this branch as it is now that we have a working setup.

[Be-ing]

Anything left to do? Merge?

[daschuer]

Yes, go ahead.

[Be-ing]

Thank you very much for your work on this tedious task. This puts us on a much more maintainable setup. It is great that we can now take care of both macOS and Windows with one tool. This is already useful for SoundTouch and libdjinterop.