hello,
On Tue, May 26, 2009 at 4:48 PM, Brian Fisher <[email protected]>wrote: > On Sun, May 24, 2009 at 9:29 PM, René Dudfield <[email protected]> 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 :). >> >> Yeah, I just used the xcode project under pm_mac and built the static lib > without any problem - note the makefiles don't work on mac, and I didn't try > a .dylib version (cause I don't see any point to doing so) so it may have > problems building. Once I copied the build products to the right place, they > got picked up fine. > ah, thanks. Yeah, I tried to do it the makefile way.
