According to what I’ve seen on the forums, if I want to use my own installation of python w/ Panda, I need to build from source.
However, when I try what (I think) is the simplest case, I’m getting a failed build.
I’ve downloaded the 1.7.2 source (windows zip file) and I am compiling w/ VS2008 pro.
Command:
makepanda\makepanda.bat --nothing --use-python
Result:
…
[ 99%] Generating ‘pandac’ tree
Could not locate the ‘direct’ python modules
Storing dependency cache.
Elapsed Time: 5 min 12 sec
Build terminated.
(Actually I tried w/ --threads=3 first, but that seemed to try to have one thread ask for something from a different thread before the 1st thread was complete. So I tried without the --threads. That’s why the Elapsed Time is so short.)
I’ve also tried building --everything, which seemed to work, but had python26.dll in the built/bin directory (I’m trying to compile for 2.7).
I’m guessing this is something simple, but I’m at a loss as to what. Would love some suggestions.
You only need to compile from source if you want to use a different version of Python than the SDK build was compiled against. The 1.7.2 build is compiled against Python 2.6, while the latest development builds are compiled against Python 2.7.
You need to replace the Python installation in the thirdparty/win-python directory to build with a different Python version. Just empty that directory, run the Python 2.7 installer, and choose that directory as installation directory. Also be sure to choose “Install for this user only”, to make sure it copies python27.dll also into that directory (as opposed to the Windows system32 directory).
Then, clear the “built” directory to enforce a clean build, and run makepanda again to build it. (I need to point out that a build with --nothing actually excludes a lot of features that you will probably want, such as a renderer module, many useful utilities, and sound support. You probably want to make sure you have the thirdparty packages in the right place and choose --everything, and maybe add some --no arguments to exclude some modules you’re sure you don’t need).
Be sure to uninstall any already installed build of Panda3D before you try to build from source.
I’ve already got python installed, so running the .msi again gave me change/repair/remove options, none of which seemed to let me install a 2nd version in the win-python directory.
I tried copying most everything from my full install, minus the Python27->Lib->site-packages over to win-python. I’ve got about 500 MB in site-packages, so using an empty directory saved a lot of space. Also why I don’t want to risk messing anything up with another installation!
However, this gives the same error. Is there a way to have the build use my existing python distribution? Looking at jGenPyCode.py, it looks like I need the root directory of Panda added to my sys.path, but I’m not sure where best to do that. I’m hoping there is a tried and true solution.
Thanks for the tip on --everything. I was intending to make sure I could compile the simple version before I tried adding in the goodies.
I think if you simply run makepanda.py (instead of makepanda.bat), it will compile Panda using whatever Python interpreter you used to invoke makepanda.py. makepanda.bat is really just a script file to find the version of Python within the thirdparty directory, so you don’t need that if you want to use your own Python.
But an easier answer might be simply to use the 1.8 version of Panda, which is already compiled to use Python 2.7 and which is really quite stable.
I’m not sure why it can’t locate the direct tree. Could it be possible that you at one point aborted the build while it was copying the “direct” tree to built/direct? If so, you may need to delete that directory and try building again to force it to copy the direct tree again.
Actually, that’s just for non-Windows platforms. Makepanda does look directly into the win-python directory in the thirdparty directory.
If I run --everything, the direct folder is copied into the built folder almost immediately. If I run --nothing --use-python (after deleting the contents of the built folder and without --threads), it does not create the direct folder. Part of my problem was that since I had been running w/ --nothing, I didn’t realize a direct folder was SUPPOSED to end up in built!
I’m guessing there is a bug (at least from my expectations) that wasn’t caught in testing since it sounds like not many people compile with --nothing --use-python as the only arguments to makepanda.bat.
I’ll work with the --everything build for now. I will look at 1.8 at some point, but to be honest, cvs is a real pain on windows. pySvn/tortoisesvn/tortoisehg have spoiled me, I guess.
Ah, that explains it. I just looked at the makepanda source and realised that one now also has to add --use-direct to include the direct tree in the build.
You don’t need to use CVS to try the 1.8 build. You can just download and install it from this page: panda3d.org/download.php?sdk&version=devel
Although it is never guaranteed to be stable at any point in time.
I can just modify the panda.pth and put it with my existing python distro to run against the built directory. Then I don’t have to bother with an installer. That’s one of the things I like about python, since you are never really sure (in general - no offense to panda) what an installer touches.
That’s the way it’s always been, on all platforms, until I changed the behaviour on OSX and Linux. Eventually I even changed it on the Windows case, but only with --rtdist.
The reason I don’t do it for the SDK build is because we ship the entire Python installation into a directory in the SDK installation, so makepanda will need to know where everything is. If we allowed it to pick up an already installed Python installation, we’re not really guaranteed to pick up the whole Python installation correctly if it’s a custom one, and there’ll also be a chance that it picks up installed site-packages and all that. Furthermore, many people will use a system-wide Python installation, which puts python2x.dll in the system32 directory, so we’d need to locate that one separately to make sure we pick it up.
So because makepanda relies on the exact location of files within the Python installation, it’d be too error-prone to allow it to pick up an arbitrary installation, not to mention the fact that the code to properly locate all the files would probably get rather hacky.
If you don’t agree though, we can certainly talk about changing this behaviour, if we properly document the intricacies involved.
I’m fine with that; and sorry, I didn’t mean to hijack the thread. I think eventually it would be nice to make makepanda behave as uniformly across platforms as possible; though I recognize that Windows’ unique quirks sometimes does require special treatment. I bet we can find a way to determine some of these things more automatically, though.
Have you thought of creating a version of Panda3d that is a python package you can install in an existing distro?
You’d only need a few versions, 2.6/2.7 maybe some 3.x if the port is easy.
But my guess is that most people do only C++ or only python, so having a python-centric install seems like it would make sense. I’m guessing I’m not the only one who doesn’t want extra installs floating around.
As for high-jacking the thread, my issue is solved. So feel free to continue the discussion if it is useful!
