Opened 4 years ago

Last modified 4 years ago

#53131 new submission

drumstick, vmpk (virtual midi piano keyboard): new ports

Reported by: mojca (Mojca Miklavec) Owned by:
Priority: Normal Milestone:
Component: ports Version:
Keywords: Cc: RJVB (René Bertin)
Port: drumstick vmpk

Description

I would like to use vmpk (virtual midi piano keyboard) that depends on drumstick.

I created a Portfile, but the software quits as soon as it starts and I have no clue how to debug it.

Open to additional maintainers and patches.

Upstream binaries crash on older OSes.

Attachments (2)

drumstick.Portfile (1.0 KB) - added by mojca (Mojca Miklavec) 4 years ago.
Portfile for drumstick
vmpk.Portfile (1.7 KB) - added by mojca (Mojca Miklavec) 4 years ago.
Portfile for vmpk

Download all attachments as: .zip

Change History (5)

Changed 4 years ago by mojca (Mojca Miklavec)

Attachment: drumstick.Portfile added

Portfile for drumstick

Changed 4 years ago by mojca (Mojca Miklavec)

Attachment: vmpk.Portfile added

Portfile for vmpk

comment:1 Changed 4 years ago by RJVB (René Bertin)

I don't have much time to look into this now, but in my own experiments drumstick is only partly functional on OS X; the only application that plays actual sound is drumstick-vpiano.

I did patch the software so that it builds as regular shared libraries, IIRC this was more or less a requirement to use if with KDE's Minuet. Building 1.1.0 is possible on 10.10 and earlier by including AudioUnit.h instead of AUAudioUnit.h .

For reference and/or perusal: https://github.com/RJVB/macstrop/tree/master/audio/drumstick .

comment:2 Changed 4 years ago by mojca (Mojca Miklavec)

Nice, I didn't check your repository before starting either. There is absolutely no hurry, I'll need to take some time to test your ports as well.

I tested drumstick-vpiano and it seems to be crashing once I press a button. The crash logs contain some references to libc++, but I'm not sure where exactly they come from. At least the version 1.0.2 compiles against libstdc++. Apparently I'll have to test on a newer OS. Just curious, why does your port use the cxx11 portgroup? I can imagine that this is indeed the only way to make it work, but I would like to understand. (Maybe version 1.1.0 is the one that requires C++11?)

I added drumstick just because I vmpk asked for drumstick-rt during configuration.

Without testing anything, you might perhaps have any clue why

-DQt5LinguistTools_DIR=${prefix}/libexec/qt5/lib/cmake/Qt5LinguistTools/

is needed to find Qt5LinguistToolsConfig.cmake. That is: why doesn't the qt5 PortGroup take care of finding its location or why doesn't Qt5 put the cmake files to a more reasonable location? (Let me guess: your patches for Qt5 already fix the issue.)

comment:3 in reply to:  2 Changed 4 years ago by RJVB (René Bertin)

Replying to mojca:

I tested drumstick-vpiano and it seems to be crashing once I press a button. The

Not for me...

Just curious, why does your port use the cxx11 portgroup? I can imagine that this

I must have seen a reference to C++11 somewhere. Using that PortGroup is a "noop" on 10.9 and up because those already use libc++ as the system C++ runtime. You're on 10.9 too, no?

Without testing anything, you might perhaps have any clue why

-DQt5LinguistTools_DIR=${prefix}/libexec/qt5/lib/cmake/Qt5LinguistTools/

is needed to find Qt5LinguistToolsConfig.cmake. That is: why doesn't the qt5 PortGroup take care of finding its location or why doesn't Qt5 put the cmake files to a more reasonable location?

(Let me guess: your patches for Qt5 already fix the issue.)

To answer that question first: yes and no. There's no need to patch Qt for that, just to let it install the files to a standard location, and that's what my port:qt5-kde does. Installing everything somewhere under libexec is nice and easy to avoid conflicts with other Qt ports, but makes things a lot more annoying for dependents. In case of Qt it isn't even necessary, and I had sufficient proof of that by the time Michael and mcalhoun started making their ports co-installable.

Mcalhoun's Qt5 PortGroup does define qt_cmake_module_dir which you can add to CMake's CMAKE_MODULE_PATH, but even the cmake 1.1 portgroup doesn't provide an easy API to append elements to that path.

That's something I should have realised before...

Note: See TracTickets for help on using tickets.