Re: [hatari-devel] Can't build Hatari on Mac if PortMidi is not installe

Nicolas, many thanks for merging the patch. The master branch builds and works ok on my Mac without PortMidi :-)

Eero, I like the idea of dummy functions in midi.h when PortMidi is not enabled. (I haven't coded C professionally for 15 years or so at this point and whenever I go back to it, the #ifdefs make me feel bad!) I can't promise to do any more work on Hatari but I do hope to become a bit more familiar with the code now that I have it building on a couple of machines. I'll see if I can understand how the SDL GUI works as well.

On Mon, 23 May 2022 at 19:08, Eero Tamminen <oak@xxxxxxxxxxxxxx> wrote:

Hi Chris,

Thanks for reporting the issue!

On 23.5.2022 19.49, Chris Jenkins wrote:
> I tried to build Hatari on my Mac (which does not have the PortMidi
> library) and found that the build was failing with the following:
>
> /Users/cdpj/GitProjects/hatari/src/gui-osx/PrefsController.m:575:21: error:
> implicit declaration of function 'Midi_Host_GetPortName' is invalid in C99
> [-Werror,-Wimplicit-function-declaration]
> while ((portName = Midi_Host_GetPortName(portName, +1, true)))
>
> It turns out that the function Midi_Host_GetPortName is not built at all if
> PortMidi is not found on the machine

I seem to have broken that 1/2 year ago with this midi.c change:
https://git.tuxfamily.org/hatari/hatari.git/commit/?id=eb4722a54d41d5ca41b2bdb771a66504934b5d28

This shows what PortMidi midi.c support code initially looked like in 2017:
https://git.tuxfamily.org/hatari/hatari.git/commit/?id=7eea8eafd7553234502183f6b14b66d9f0d5e164

> but that the Mac UI code that calls it
> _*is*_ built (and fails because the function definition doesn't exist).

This shows all the places where PortMidi support was integrated to OSX
GUI initially:
https://git.tuxfamily.org/hatari/hatari.git/commit/?id=27ec2eb04e9adf9d0292f2c9ef4805eb9a2dc450

> Attached is my initial attempt to fix it. Note that this is my first
> attempt to contribute code to Hatari so I'm unsure whether I've done the
> right thing. In particular, I'm not sure if it's ok to #ifdef out parts of
> the UI initialisation code, or precisely how much to #ifdef out. I'm
> interested in any feedback on the approach.

I'm not sure what's the best place to put the ifdefs:
* Ifdef out just calls to non-existing midi.c functions, like you did
* Ifdef all PortMidi related code out of OSX GUI code, not just calls to
midi.c functions
* Add ifdefs back to inside of the midi.c functions
* Provide separate dummy functions in midi.h when PortMidi is not
enabled (like Linux kernel project does to minimize places where ifdefs
are needed)

My preference would there to be MIDI device support without PortMidi
also in the OSX GUI, not just in the SDL GUI.

I mean, MIDI devices are used also for other things than MIDI events,
like debug output and networking. PortMidi does not work for those
use-cases, for that one needs to be able to specify a file name instead,
when PortMidi support is not enabled.

(Among other things, this doc includes examples of how to forward Hatari
MIDI device data over internet:
https://hatari.tuxfamily.org/doc/midi-linux.txt)

- Eero