The Mixxx 2.3 beta was released in June, though I haven't been able to find an estimated release date for the final version. For porting, the major change is a transition to CMake for the build instead of SCons (see bug 247189). I've opened this bug to document changes for building Mixxx 2.3 with CMake, currently with the latest git snapshot of the 2.3 branch. I think most changes for porting the (upcoming) new version will just be adaptations of the existing patches for the new build system. Here's what I've done so far to try to make it build: - add security/qtkeychain, sysutils/upower, comms/hidapi as dependencies. (Some of these are patched out in the current port.) - portmidi: rather than patching this out, I think the best solution would be to add a new portmidi port. After downloading the sources, I tried the following changes to build: - configure script using ccmake is interactive. I had to manually specify the JAVA_INCLUDE_PATH and JAVA_JVM_LIBRARY paths as described in `portmidi/trunk/pm_linux/README_LINUX.txt`. The paths depend on the installed JDK version. There must be a good way to do this automatically. In my case, these paths are: JAVA_INCLUDE_PATH=/usr/local/openjdk8/include and JAVA_JVM_LIBRARY=/usr/local/openjdk8/jre/lib/amd64/server/libjvm.so - add `/usr/local/include` to `include_directories` on line 68 of portmidi/trunk/CMakeLists.txt - set the env variable LIBRARY_PATH=/usr/local/lib in order to find asound library from alsa, may be better to instead patch in the `-L/usr/local/lib` flag throughout the source files - patch two functions using deprecated `ftime` to use `gettimeofday` in `porttime/ptlinux.c` (c.f. https://forum.freecadweb.org/viewtopic.php?t=15724). For the default make target, I get this error around 93%: make[2]: don't know how to make pm_java/jportmidi/JPortMidi.class. Stop It is possible to patch out portmidi: keep existing patch to controllers/controllermanager.cpp, remove REQUIRED keyword in CMakeLists.txt for PortMidi, comment out `portmidicontroller.cpp` and `portmidienumerator.cpp` around line 2365 of CMakeLists.txt. However, this causes build failures later on that I haven't yet figured out. - use system libusb. I'm not sure how to make this happen in CMakeLists.txt (see lines around 2260). I don't use a USB controller, and configure succeeds if the feature is disabled (cmake -DHID=off ...). It should be possible to pass the flags '-DLIBUSB_INCLUDE_DIR=/usr/include -DLIBUSB_LIBRARIES=/usr/lib/libusb.so' to the configure command, but this fails in logic around lib-hdiapi. - add include directory for ogg.h in libshout. There may be a better way to do this, but I just added `/usr/local/include` to `include_directories` in `lib/libshout/CMakeLists.txt`. - change `endian.h` to `sys/endian.h`, and `byteswap.h` to `infiniband/byteswap.h` in lib/kaitai/kaitaistream.cpp With these changes (patching out portmidi since I haven't succeded in building it yet), mixxx 2.3 configures successfully and builds partially (12%), failing eventually with: In file included from /home/david/Downloads/mixxx/cmake_build/mixxx-lib_autogen/T7JLZL2D4I/moc_portmidicontroller.cpp:10: /home/david/Downloads/mixxx/cmake_build/mixxx-lib_autogen/T7JLZL2D4I/../../../src/controllers/midi/portmidicontroller.h:20:10: fatal error: 'portmidi.h' file not found #include <portmidi.h> ^~~~~~~~~~~~
portmidi builds successfully with the above procedure if *gmake* is used instead of BSD make. I'll open a separate issue for a new portmidi port separately when I have a ports Makefile working.
Hi, any progress here? I'm having a midi controller (ddj-400) which should be supported with 2.3 natively and isn't found (the midi device) with the current port. Or is there something special needed for Midi devices..
Version 2.3 was finally released today: https://mixxx.org/news/2021-06-28-mixxx-2-3-0-released/ When I have some time, I'll take another look at building it for ports.
Hi, Mixxx maintainer here. I've been thinking about forking PortMIDI and writing a modern CMake build system for it. This would also help us switch to using vcpkg for our macOS dependencies and would be helpful for Tenacity as well. Would you be interested in helping with this? If you run into more issues packaging, please get in touch on our Zulip chat ( https://mixxx.zulipchat.com/ ) and/or open PRs on GitHub ( https://github.com/mixxxdj/mixxx ).
I have imported the old PortMIDI SVN repository to a new Git repository under the mixxxdj organization: https://github.com/mixxxdj/portmidi Unfortunately it looks like PortMIDI does not support FreeBSD. Pull requests welcome.
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=1819836d4cb2bb8cef3680fb1059eb6ae9e491fb commit 1819836d4cb2bb8cef3680fb1059eb6ae9e491fb Author: Jose Alonso Cardenas Marquez <acm@FreeBSD.org> AuthorDate: 2021-07-17 17:33:18 +0000 Commit: Jose Alonso Cardenas Marquez <acm@FreeBSD.org> CommitDate: 2021-07-17 17:37:47 +0000 audio/mixxx: Upadte to 2.3.0 ChangeLog at: https://github.com/mixxxdj/mixxx/blob/2.3.0/CHANGELOG.md PR: 249348 Reported by: fbsd-bugzilla at schlachter.ca audio/mixxx/Makefile | 102 +- audio/mixxx/distinfo | 6 +- audio/mixxx/files/patch-build_depends.py (gone) | 159 -- audio/mixxx/files/patch-build_features.py (gone) | 102 - audio/mixxx/files/patch-build_mixxx.py (gone) | 27 - audio/mixxx/files/patch-build_qt5.py (gone) | 11 - .../patch-cmake_modules_FindLibUSB.cmake (new) | 14 + .../patch-lib_hidapi-0.8.0-rc1_libusb_hid.c (gone) | 11 - .../files/patch-lib_kaitai_kaitaistream.cpp (new) | 14 + ...orp_SPSCQueue_include_rigtorp_SPSCQueue.h (new) | 11 + ...-plugins_soundsourcem4a_soundsourcem4a.h (gone) | 11 - .../files/patch-src-encoder_encodermp3.cpp (gone) | 11 - .../files/patch-src-util_screensaver.cpp (gone) | 27 - ...ch-src_controllers_controllermanager.cpp (gone) | 12 - ...trollers_controllerpresetfilehandler.cpp (gone) | 14 - .../files/patch-src_util_versionstore.cpp (new) | 11 + .../files/patch-vamp-plugins_SConscript (gone) | 11 - audio/mixxx/pkg-plist | 2654 +++++++++++++++++++- 18 files changed, 2745 insertions(+), 463 deletions(-)
I've been trying out the 2.3 port, everything works great. Thanks so much!
Why wasn't I notified of the need for a port of audio/portmidi? My completed port has been sitting in bugzilla since late last year, untouched for over 7 months, now pushing 8. If a ports committer checked for new or open PRs, or committed it way earlier (as early as late last year), it may have saved people some time and effort. If there was something wrong with it, I would have tried my best to address any issues or shortcomings, with no upstream active at the time that I ported it. I saw no activity or interest to get it committed, and while I applaud this urgency to port niche but important libraries, I am pretty demotivated by the way this went down and feel like I'm wasting my time. I don't fault anyone for this happening, as the circumstances doesn't look like there were ill intentions on anyone's part, but as it stands, I wasted a ton of time porting it, only to have my work completely thrown away, or even given any credit or recognition at all for a fairly difficult port as if my PR never existed (https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=252186, and a cursory search for "portmidi" reveals two PRs that I have authored). This scenario could have been avoided completely if my PR were handled earlier by committers, or if someone told me something that needed to be fixed if it wasn't up to standard. I understand that committers are tremendously overburdened, but I have a lot of ports almost ready to go, just sitting here bitrotting, many like portmidi since last year, and I don't ever want to put in a lot of time and energy again to just have my work never used and ignored. That's incredibly discouraging. I applaud the new upstream of portmidi, who are taking a proactive approach and are committed to supporting multiple platforms properly, and look forward to working with them on getting some version of that work incorporated at a later date. I'm thrilled to see these ports happening, but I didn't expect to this situation unfold in this particular way.