I’m trying to build Panda in a C++ Win32 console application, using Visual Studio 2008. When I try to build in debug mod, I’m told that the file python26_d.lib cannot be opened. When I build in release mode, I get a bunch of errors, starting with the panda iostream file.
I’ve addedthe following include directories to the project:
C:\Panda3D-1.5.4\include
C:\Panda3D-1.5.4\python\parser-inc
C:\Panda3D-1.5.4\python\include
And the following library directories:
C:\Panda3D-1.5.4\lib
C:\Panda3D-1.5.4\python\lib
Am I missing anything? What might cause these errors? I’ll provide more information as needed.
I did already have python installed, but I’m not pointing visual studio to that directory. Any idea what I can do to fix it? I do need that version of Python installed, though.
I"m thinking maybe I"m not including the right things. Is there a list of the things that I need to include to get a panda project to compile successfully?
(1) You can’t make a debug build of Panda, unless you also go find or make a debug build of Python, and of all the other thirdparty libraries. Microsoft won’t let you mix-and-match debug and release builds in the same executable, so it all has to be the same. That’s what the _d means: it’s looking for a debug build of Python. So, restrict yourself to a release build unless you want to go build a bunch of additional stuff first.
(2) Don’t add the parser-inc directory to the include path. The files in there are not intended to be read by the compiler. The other directories are correct, though.
Okay, I was including C:\Panda3D-1.5.4\python\lib, but what I needed was C:\Panda3D-1.5.4\python\libs. What a difference a letter makes.
It’ll build in release mode, but not debug mode, which I now see the post telling me that wouldn’t work. So there’s no way to access a debugger in a panda app? That seems a bit… bad.
You can certainly debug a panda app built in release mode. The debugger is just a little less accurate, particularly for showing you the values of local variables (a lot of these get optimized away and don’t exist where the debugger can query them).
Or, you can build the whole world in debug mode. People have done this, it’s not outrageous. It just takes a while, and you have to be fairly comfortable with building C++ projects.
There might be another option. You might be able to build in release mode, but disable compiler optimizations even though you are in release mode. This should make the debugger accurate again, but you won’t be using the debug heap, which is what causes the conflict between mixing debug and release builds in a single application. This is kind of advanced, though, and you should know what you are doing if you fiddle with these settings.
Ah, okay. I forgot that you can debug in release mode. I’d gotten burnt by the anomalies of doing that a while back and must have blocked the option out in my mind.