On Tue, May 26, 2009 at 4:48 PM, Brian Fisher
<brian@xxxxxxxxxxxxxxxxxxx> wrote:
On Sun, May 24, 2009 at 9:29 PM, René Dudfield
<renesd@xxxxxxxxx> wrote:
> I believe Brian doesn't have portmidi.dll installed.
>
I definitely don't have any separately installed portmidi shared library on any machine of mine, but I don't think that one is required on OS X or Windows for proper operation. I think both build bots are getting at the portmidi library just fine.
Also, as a rule, I think ever requiring a separately installed and managed library that's not a standard OS component on Win and Mac is the wrong way to do things. Those platforms don't have package managers and Kernel components are quite stable, so therefore is both no good way to manage dll dependencies and there is no benefit to calling out to a shared separately managed version of portmidi vs. statically linking/including the version we tested into pygame, respectively.
k
I think he does have it installed on at least the windows installs.
My windows build box has portmidi.dll in the prebuilts dir, so if the setup for making the installer for pygame picks that dll up properly, then it should be getting that dll just fine.
Cool. I think Lenard has made a new prebuilts one that doesn't printf debugging info.
from the build output, it looks like the problem is pygame.midi.get_device_info is returning None - I can tell you my build machines definitely don't have midi devices (neither physical nor virtual) configured, and None seems an appropriate return value in such cases. Maybe it's just the tests are bad for a machine with no midi devices?
cool. I thought as much - since the init/quit tests seemed to pass.
Will fix the tests. Will likely tag them interactive, or make them skip if there's no midi devices.
I also didn't want to write output to any midi devices... in-case it woke you up at 3am with some "Electric piano 1" notes or something :) So will tag those tests 'interactive'.
Brian, can you confirm if it's installed on the OSX build bots?
My OS X machine definitely has the static portmidi library (libportmidi.a) and header file (portmidi.h) in the right places (/usr/local/lib and /usr/local/include) because they are getting picked up and built in by config.py. I built libportmidi.a myself, and I know it's the static lib, not a linking lib for a dylib or .so or anything like that.
Cool.
Also, do you know how to compile portmidi on OSX? I couldn't get it
to compile on OSX (if you can't remember I'll try and work it out :).