fwcd / m1xxx Goto Github PK
View Code? Open in Web Editor NEWUnofficial native Mixxx builds for macOS (Apple Silicon/Intel) and Linux
License: Other
Unofficial native Mixxx builds for macOS (Apple Silicon/Intel) and Linux
License: Other
Since scheduled GitHub workflows unfortunately only run on the default branch, we'd have to modify main
's workflow accordingly, e.g.
diff --git a/.github/workflows/update-mixxx.yml b/.github/workflows/update-mixxx.yml
index 0715f62..500cc06 100644
--- a/.github/workflows/update-mixxx.yml
+++ b/.github/workflows/update-mixxx.yml
@@ -9,10 +9,14 @@ on:
jobs:
automerge:
runs-on: ubuntu-latest
+ strategy:
+ matrix:
+ branch: ['2.4', 'main']
steps:
- uses: actions/checkout@v3
with:
+ ref: '${{ matrix.branch }}'
fetch-depth: '0' # to compute the monotonic version correctly
submodules: true
- name: Configure Git user
The issue is that the build currently depends on a workflow_run
trigger, for which I am not sure if it triggers in the way we would expect across branches: Given that the scheduled workflows run on main
, 2.4's build workflow would likely not end up being triggered. We might be able to work around that by using e.g. a repository_dispatch
event, but I am not sure if workflows on non-default branches will receive these events. This would be something to investigate.
We could e.g. generate a list of the added commits (perhaps only the merge commits/PRs) from the last release.
For some reason this hash check is failing again
The release artifacts are currently overwritten even if the release already exists/the version hasn't changed. This leads to broken checksums in the Homebrew repository. We should fix this by e.g. not overwriting release assets or by automatically updating the Homebrew repository (e.g. via a repository_dispatch
event? This would however muddle the clean separation between homebrew-fwcd
polling for changes and this repository).
This would however require automatically tracking Mixxx's dependencies, which might first be possible once they migrate to manifest mode.
We should cherry-pick whatever we can use from main
(Linux support probably won't work with our patched Qt 5.12).
E.g. with the ability to specify a list of PRs to include. We could either model this by automatically updating a fork of Mixxx or by dynamically applying the merges during CI.
A slightly adjacent idea would be the ability to build with different vcpkg environments, e.g. different Qt versions. Since this is generally non-trivial to perform automatically, we would likely have to pin a custom vcpkg revision for that.
This would be nice for use on a Raspberry Pi, especially given that from-source builds under QEMU take very long. We'd have to figure out whether building all the dependencies from scratch via vcpkg is the right approach or whether using the distribution-provided libraries would be better after all.
See title, this variable from qt_port_hashes.cmake
isn't being updated correctly.
A cron
-scheduled workflow for building regular nightly versions of Mixxx would be cool (though we should tackle #5 first).
See this GitHub blog post. We should migrate to updating the env, as described in this doc.
Statically building Mixxx on Linux (using vcpkg) is not officially supported by upstream, but is still nice-to-have and exercises some corner cases that the standard builds using system packages don't.
mixxxdj/vcpkg
Now that the main
branch can be built directly without patches (see #5), we would simply have to regularly update the mixxx
submodule to point to the recentmost main
commit.
Many of the blockers mentioned in the README (in particular waveforms requiring a legacy widget to render, thus preventing an update to a newer Qt version) are no longer applicable as of
We should therefore update the description to reflect the current status and ideally make the link to the official ARM snapshots more prominent (especially once a stable ARM version is released).
There are also still a few minor issues with the official snapshots that this unofficial build doesn't have, in particular this signing/sandbox-related issue:
Caching artifacts with ccache (in conjunction with the GitHub Actions cache) would be cool.
macOS 10.15 runners are deprecated and upstream did so too:
The wasm
branch contains experimental forks of mixxx
and vcpkg
for targeting wasm32-emscripten
.
You can try it out, there is a GitHub Pages-hosted build at https://fwcd.dev/m1xxx, but be warned: It may take a while to load (tne Wasm binary is ~300 MB, the assets are ~90 MB) and there is no audio (the experimental "Web Audio" backend is not functional yet, hence why it is disabled by default).
On the technical side, there are still some major roadblocks to be resolved:
-sASSERTIONS
, see
-sASSERTIONS
, any multiple in-flight async operations are effectively undefined behavior and manifest themselves in hard-to-debug failures at runtime (e.g. "unreachable" errors in the console, freezes, etc.)Something to investigate would be whether we could replace -sASYNCIFY
entirely with -sPROXY_TO_PTHREAD
, i.e. move the "main" thread to a Web Worker where we can block synchronously. Unfortunately, there seem to be some complexities involved in making this work with Qt:
We may have to check whether setting USE_PTHREADS=1
for Qt would help here (or whether that would be redundant because our vcpkg triplet already sets -pthread
).
Another option would be the recently-added C++20 co_await
integration, which uses native LLVM coroutines and thus hopefully shouldn't be bound to the same limitations as Asyncify: emscripten-core/emscripten#20413
Given that PortAudio exposes a C interface, I am not sure how well we could integrate C++ coroutines there, however.
Being able to run Mixxx on the web would be pretty cool. Qt supports WebAssembly, we would however also have to compile all of the other dependencies. This would probably take some work, but should not be impossible.
We take a similar approach to the iOS port (#16) and use custom WASM branches for mixxx
and vcpkg
, along with an integration branch in m1xxx
, then gradually upstream the required changes.
dbus
libflac
, libmad
and libmodplug
sleef
build by using fftw
as an alternative FFT backendqttools
build (or figure out how to remove non-host qttools
dependency from qttranslations
)
qttools
_qt_test_emscripten_version
in Qt6WasmMacros.cmake
during Mixxx configure
WrapRt
cannot be found when configuring Mixxx:
Qt6Core could not be found because dependency WrapRt could not be found.
FindWrapRt.cmake
shows that the check_cxx_source_compiles
failed, which (as build/CMakeFiles/CMakeConfigureLog.yaml
revealed), failed due a missing clang-scan-deps
binary:
"CMAKE_CXX_COMPILER_CLANG_SCAN_DEPS-NOTFOUND" -format=p1689 -- /opt/emsdk/upstream/emscripten/em++ -DHAVE_STDATOMIC_WITH_LIB -fdiagnostics-color=auto -std=gnu++20 -x c++ /Users/fredrik/git/m1xxx-wasm/mixxx/build/CMakeFiles/CMakeScratch/TryCompile-QIjor4/src.cxx -c -o CMakeFiles/cmTC_0948e.dir/src.cxx.o -MT CMakeFiles/cmTC_0948e.dir/src.cxx.o.ddi -MD -MF CMakeFiles/cmTC_0948e.dir/src.cxx.o.ddi.d > CMakeFiles/cmTC_0948e.dir/src.cxx.o.ddi.tmp && mv CMakeFiles/cmTC_0948e.dir/src.cxx.o.ddi.tmp CMakeFiles/cmTC_0948e.dir/src.cxx.o.ddi
/bin/sh: CMAKE_CXX_COMPILER_CLANG_SCAN_DEPS-NOTFOUND: command not found
ninja: build stopped: subcommand failed.
FindWrapRt
check).
wasm-ld: error: --shared-memory is disallowed by sqlite3.c.o because it was not compiled with 'atomics' or 'bulk-memory' features.
-pthread
(as per this discussion). This should in principle be possible via the triplet, just setting VCPKG_C(XX)_FLAGS
does not work, however:wasm32-emscripten-pthread(-release)
) and setting
set(ENV{EMCC_CFLAGS} "$ENV{EMCC_CFLAGS} -pthread")
microsoft/vcpkg
mixxxdj/vcpkg
TBD:
IDBFS
to persist the .mixxx
directorycpack -G TGZ
is used
bin
etc.mixxx.{data,html,js,wasm,worker.js}
, qtloader.js
and qtlogo.svg
emrun mixxx.html
can be used to launch the web app locallyThis would let us produce proper dependency archives (the current ones cannot really be used to compile Mixxx on arm64 hosts since the Qt tools are still built for x86_64 in CI).
Probably a silly question, but I am new to mac world so not sure: will m1xxx fork work for m2 (macbook air 2022)?
Currently the repo only builds the dependencies, not Mixxx itself yet. We should do so and perhaps figure out whether we could pass the (relatively few) patches to the CMake build files as command line arguments to avoid having to patch the mixxx
tree itself (this would also make it easier to e.g. provide regularly updated nightly builds of Mixxx, at least while the dependencies don't change).
This would also help us get rid of the vars
scripts.
Hi,
Firstly, thanks for the work you've done making an m1 build available, it's really nice to have it running natively!
Unfortunately, I haven't been able to get my DVS setup working, the program does not detect the timecode signal coming from the audio interface. I suspect it might be because m1xxx does not request microphone access when starting up.
I didn't observe this behaviour with the official (intel) build, any idea what the issue could be? My best guesses are that the builds based off master do not currently support this, or alternatively, that the fact that this is an unofficial build restricts the access given to the program (launching the app requires going into system preferences and clicking "Open anyway"). I'm not a macOS expert, so any help with this would be amazing!
This should likely be able to piggyback off most of the work on iOS support (#16), we might have to configure Mixxx to omit the storyboards when targeting tvOS.
The ios-qt6
branch contains experimental forks of mixxx
and vcpkg
that support compiling Mixxx and its dependencies for iOS, i.e. for arm64-ios-release
. Most changes to Mixxx have been upstreamed, vcpkg upstreaming is still in progress. iOS CI passes.
scripts/install-vcpkg-deps
with the arguments given in the aforementioned instructions should pass)
ffmpeg
build by setting --disable-audiotoolbox
libusb
and hidapi
for nowvcpkg/overlay/ios
mp3lame
by setting --disable-frontend
(otherwise the build would error with missing curses.h
headers)portaudio
by patching in an experimental iOS CoreAudio backend (source)portmidi
by patching use of legacy Carbon APIs and unavailable CoreAudio APIs (e.g. by replacing the hosttime calls with the mach time APIs as suggested by this Q&A doc)rubberband
due to licensing issues (GPL + App Store) and build issues_debug
suffix for libraries (not needed since we already place them in a /debug
subfolder, additionally they cause the Mixxx build to fail as Qt5CoreConfig.cmake
looks for unsuffixed libraries (e.g. libQt5Core.a
instead of the actual libQt5Core_debug.a
))gles3
feature to qtbase
(otherwise the port is identical to upstream vcpkg)opengl
, gles2
, gles3
and sql-sqlite
, but not sql-psql
)harfbuzz
with iOS sdkrootarm64-ios-simulator-release
(instead of arm64-ios-release
)mixxx.xcodeproj
with the cmake
command in the READMEQIOSIntegrationPlugin
RUBBERBAND
)
QFileChooser
in MixxxMainWindow::slotFileLoadSongPlayer
, which is invoked by File > Load Track to Deck ...
)
MediaPlayer
(instead of iTunesLibrary
) framework to access music library on iOS
qResourcePath
logic to handle iOS app bundles (which use a flatter file structure than macOS bundles)IOS
variable is not automatically set by CMake when setting CMAKE_SYSTEM_NAME
to iOS
project
call. We check the vcpkg triplet instead now and set CMAKE_SYSTEM_NAME
automatically as needed.TBD:
RUBBERBAND
, HID
, BATTERY
, QTKEYCHAIN
) for iOS in upstream CMakeLists and remove them from our README (and user presets as needed)
rubberband
and qtkeychain-qt6
have been fixed, so we could investigate reenabling themmicrosoft/vcpkg
mixxxdj/vcpkg
TBD:
vcpkg.json
manifestSDKROOT
workaroundsTBD:
SDKROOT
for some portsi.e. use arm64-osx-min1100-release
instead of arm64-osx-release
and x64-osx-min1015-release
instead of x64-osx-release
etc. by default in scripts/install-vcpkg-deps
. Both our and upstream's CI already uses these by explicitly specifying the corresponding triplets, but it would be nice to do this for local developers too to fix the corresponding linker warnings when building Mixxx.
Since we need the binary dependencies for building Mixxx already, we could provide it as an artifact too (this could be convenient for building Mixxx locally on Apple Silicon without having to build all the dependencies manually).
We should clarify that we're building against glibc 2.35 since that's what Ubuntu 22.04 (Jammy) uses.
$HOME
is not resolved in this context, so the current solution does not work:
m1xxx/.github/workflows/build.yml
Line 124 in fa780e5
We can, however, use ~
to resolve the directory, see:
#48 addresses this by adding ccache_path
to the matrix with the correct paths. If that PR turns out to be a larger blocker, we might consider extracting that logic (including the step that saves the ccache even if the run fails).
Once the scripts from #9 are merged, we should update the README with a short description on how to build Mixxx locally on arm64 macOS.
Upstream did, so we should too: mixxxdj/vcpkg#80
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.