interrogate on existing Panda installation

C++ coding using Panda3D
1

Is it possible to use interrogate to generate wrappers for Python 2.7 using an existing installation of the Panda3D SDK, or do I have to rebuild the entire source tree?

2

Umm, you mean, you have a version of Panda that’s already been compiled for some different version of Python, and you’d like to rebuild it for Python version 2.7 without recompiling?

This isn’t really possible with our current build scripts. But rebuilding all of Panda isn’t that difficult; you should just do that.

David

3

That was my hope. I wasn’t sure how the build scripts operated internally, so it seemed plausible that the Python modules might be dynamically linked to the main Panda library, rather than statically linked, in which case those might be rebuilt separately.

Is it documented anywhere which configuration settings are used to produce the official builds? It would be nice to have a drop-in replacement (with Python 2.7 instead of 2.5).

4

The command used for the Windows build is:

call makepanda\makepanda.bat --everything --installer --lzma --verbose --nocolor --distributor cmu --no-sse2

Most of those options don’t change the nature of the build, however, so it’s not all that important.

Panda3D is already built with (and ships with) Python 2.7 since 1.8.0, and since that command will build against the Python version in thirdparty/win-python , that should build for 2.7.

5

Hmm, I’m running 1.8.0 on OS X, and as I can tell the official release is still built to run with Python 2.5. Are any of the options much different for a Mac build? i.e. --no-direct-x or anything like that?

6

Sorry, I don’t know why I thought you were on Windows, I must have mixed you up with someone from a different thread. On a non-Windows system, makepanda builds against whatever version of Python that you run makepanda with. The default releases are built on Leopard, using the default Python version there (which is 2.5).

On Mac OS X, you can simply install the XCode Developer Tools, then download the source archive (the one that includes the thirdparty packages), and then simply run makepanda with the version of Python that you want to build against (ie. python2.7 makepanda/makepanda.py). I build Panda against Python 2.7 on my own Mac that way.

For the record, the flags used for the official Mac OS X build are:

python makepanda/makepanda.py --everything --installer --verbose --nocolor --distributor cmu --universal --osxtarget 10.5

But again, these are largely unimportant, it should build just fine with just --everything --installer for your purpose.

7

Thanks very much! One thing I noticed is that the Python scripts in the build system all use

#!/usr/bin/python

instead of the more well-mannered

#!/usr/bin/env python

Is there explicit reasoning behind this decision, or is it something that might be considered to be changed in later versions?

8

No particular reason, I suppose that most people explicitly put “python” in front of the command so it has never been an issue. I’ll change it to the more “well-mannered” version.

9

Between people who explicitly type python first, and the majority of people who simply have their python installed in the usual location, I wouldn’t expect it to come up very frequently. However, MacPorts installs to the /opt/local/ directory tree rather than the /usr/ directory tree (and I think most other Unix-style package managers on OS X do as well), and is also the easiest way for Mac users to come by most of the other “useful” packages for application development in Python (NumPY, PIL, wxPython, etc).

Hopefully this will save someone a headache down the line (it occurred to me to check before I ran makepanda when you said that it would build Panda against whichever Python was used to invoke the build system).

Thanks for the speedy response!

10

Sorry for the double post here, but I thought I’d keep it to one topic since I’m still working on the same issue.

Is there somewhere I could find 32/64-bit fat binary versions of the third party libraries? I just discovered my Python 2.7 defaults to 64 bit, and many of the other libraries on my system (Lion) are 64 bit only. I ran into a bit of trouble with the Carbon dependencies in the osxdisplay libraries, but found that you had Cocoa friendly versions in the devel branch and have attempted a back-port into my 1.8 source tree. Unfortunately, it seems most of the libraries are compiled 32 bit only. Is there a download link for the devel version of the source tree including the thirdparty directory with 64-bit friendly libraries?

11

I’ve been rebuilding some of the thirdparty packages with 64-bit support. It’s not complete yet, some are missing (most notably ffmpeg), but here you go:
rdb.name/thirdparty_mac_x86_64.tar.bz2

You’ll have to build any others you might need from source for the moment, sorry. I do have OpenCV since I last updated that tarball, so let me know if you need that as well.

I hope to have a complete tree soon, at which point I’ll also enable 64-bit development builds.

12

Hopefully MacPorts will cover me on the ffmpeg front. I can’t think of any uses for OpenCV in the near future so I’ll just disable that for now. Thanks again for the help :slight_smile:

13

Another double post - I gave up on my hack-and-slashed Cocoa 64bit 1.8 after a handful of problems cropped up and just went straight for compiling devel.

Some things to note that I came across:

I also needed to download the XCode Auxiliary Tools from ADC (which are no longer included by default with App Store-XCode), and update the path in makepanda.

However, as far as I can tell, it’s functioning.

14

These warnings are perfectly ignorable and are due to the size of certain macro definitions. Really this is just the compiler being overly fussy.

David