Mixxx for macOS on M1/M2 Apple silicon #11398
Conversation
|
All green. |
tools/windows_buildenv.bat
Outdated
| @@ -1,6 +1,6 @@ | |||
| @ECHO OFF | |||
| SETLOCAL ENABLEDELAYEDEXPANSION | |||
| REM this � is just to force some editors to recognize this file as ANSI, not UTF8. | |||
There was a problem hiding this comment.
The encoding of this file is broken - please make a binary diff.
There was a problem hiding this comment.
Fixed. This is always a pain. Not sure which editor here is broken.
There was a problem hiding this comment.
GitHub Diff still marks this line as changed
There was a problem hiding this comment.
Oh sorry. This is fixed now and I have created #11513 in order that this will not happen again.
tools/windows_buildenv.bat
Outdated
| @@ -25,6 +21,10 @@ IF NOT DEFINED INSTALL_ROOT ( | |||
| SET INSTALL_ROOT=%MIXXX_ROOT%\install | |||
| ) | |||
|
|
|||
| SET BUILDENV_NAME=mixxx-deps-2.4-x64-windows-8f8342a | |||
| SET BUILDENV_BRANCH=2.4-rel | |||
There was a problem hiding this comment.
Our reviewed buildenv is in branch 2.4 not 2.4-rel.
I guess this will break the Debug builds for local Windows developers - not tried yet.
Downloading of the buildenv happens before the developer selects if he want to build Debug or Release.
There was a problem hiding this comment.
You can still use the 2.4 branch for debugging on windows. Just download and replace the folder.
The 2.4-rel branch is the default for GitHub workflows because the debug libraries are not used there.
This means we get exact the same binary result if we use the 2.4 branch or the 2.4-rel branch.
There was a problem hiding this comment.
Why do we need two source branches in Git to build two sets of binaries?
There was a problem hiding this comment.
Because the triplets files have the same name, but different content. mixxxdj/vcpkg@c2c93b5
We need also a different branch so that the packages are going into two locations named by the branch on https://downloads.mixxx.org/dependencies/2.4-rel/
There was a problem hiding this comment.
If it's just the value of this one CMake variable VCPKG_BUILD_TYPE, please set it from outside.
Or, if this is not possible, generate the 5 files in overlay/triplets on the fly during the build of the VCPKG buildenvs.
There was a problem hiding this comment.
I have probably not understand what you want.
Do you want to create the release builds and the combined debug/release build from a single workflow run?
There was a problem hiding this comment.
I request two things:
- Compile all build environment ZIP-Files from the same VCPKG branch
- Use the full build environment ZIP-File (with Debug and Release DLLs) for local builds by default.
There was a problem hiding this comment.
- Does the opposite of the original intend. It will populate the cache during PR builds with the more code than with less. It is very convenient to develop with the release only version and reducing the build time to 3 hours instead of 5. That makes a difference.
- That means that every casual contributor on windows will need to download 1.3 GB instead of just 530 MB. Unpacked the environment consumes 5 GB instead of 3 GB. Why should that be the default? How about offer both options equal easy, that the user can make the choice?
There was a problem hiding this comment.
The new approach addresses 2. well!
To make it safe, please make line
mixxx/tools/windows_buildenv.bat
Line 181 in 22e20ae
conditional too.
This is an unnecessary redirection of information
This allows to easily switch between diffrent branches of our vcpkg repository
|
Nice, very excited to see official support for arm64 macOS moving forward 👍 From some quick smoke testing everything seems to work well. Interestingly this also solves fwcd/m1xxx#23 and correctly displays ARM64 in the about panel even though it's a cross-build, I must have missed something in my builds. |
daschuer
force-pushed
the
arm64_macOS
branch
4 times, most recently
from
39c90c4 to
d85e8f6
Compare
|
I consider this now as ready to merge. The open topic for discussion, a joint vcpkg branch, is unrelated to this PR. |
I agree! |
|
OK @JoergAtGithub, so we can merge this? |
|
I've not tested the windows build yet. If this works as expected, I'm fine with the changes - but I can't test the MacOS stuff. |
tools/windows_release_buildenv.bat
Outdated
| @@ -0,0 +1,2 @@ | |||
| @ECHO OFF | |||
| set DEFINED BUILDENV_RELEASE=TRUE && call "%~dp0windows_buildenv.bat" %* & set DEFINED BUILDENV_RELEASE= | |||
There was a problem hiding this comment.
| set DEFINED BUILDENV_RELEASE=TRUE && call "%~dp0windows_buildenv.bat" %* & set DEFINED BUILDENV_RELEASE= | |
| set "BUILDENV_RELEASE=TRUE" && call "%~dp0windows_buildenv.bat" %* & set "BUILDENV_RELEASE=" |
This doesn't work for me. Are you sure, that CI used the release only buildenv?
|
Could you please add a suffix to the files in |
|
@JoergAtGithub this is now read to merge. |
This updates * protobuf * libusb * libmad * portaudio See: mixxxdj/vcpkg#66
|
Code looks good to me now, but I haven't tested it on Windows yet. Did anybody tested this on Macintosh? |
|
The vcpkg environment has been tested here: |
|
I just tested this PR on Windwos11 and both build environments work for me! |
|
Thank you ,🚀 |
This is the final step to bring Apple silicon support to Mixxx
It also enables hash checks for the integrity of the windows environment and disposes the hard to find "build_environment" files in the packaging folder. It uses the release only environment that will free up some space in our workflow cache.