Building Full Panda3D source using makepanda

I would have tested pview too, that would have tested at least the C++ part of the build, which might be informational. If pview works but Python doesn’t, it at least narrows down where to look for the problem.

David

Yeah, especially since by default, MSVC will quibble over a lot of relatively minor things, such as signed/unsigned mixes with comparison.

I do remember there being something wonky with ODE under the CVS HEAD, but I can’t tell you exactly what it was. I just included --no-ode because I’m currently not using it.

My guess is it’s the same as ffmpeg in the thirdparty bundle – Something changed, and now Panda3d is referencing something that is not there or vice versa.

I’m not at my home computer right now, however, turns out the build didn’t “suceed” like MSVC says, because the python interpeter returned a runtime error due to a missing file. Something about *freeze.py… This is with --no-ode --no-tinyxml --no-ffmpeg.

When I get home I will try what David said and use the source provided on the site and only update makepanda. If for some reason the CVS head of makepanda will break when compiling the source, it’d be nice if I could have info on what exactly is breaking, because technically it should work.

OK, that is indeed some of the new stuff I’m working on right now. I could probably tell you more with the precise error message.

I think you will have similar issues trying to use the new makepanda with the old Panda source. It would be possible to build a correct makepanda that has all of the stuff for building debug Panda properly, and also builds properly against 1.6.2 Panda, but this would require a merge from different versions of the repository. I now think it was a bad idea on my part to suggest this attempt; it’s probably better to figure out what was broken with makepanda against the head of cvs, and fix it. It sounds like it isn’t very far off from 100% correct.

Another possibility is to go ahead and try using the ppremake build instead, which is not really all that difficult, though I do think we are closer with the makepanda solution.

Sorry about all this. You just happened to get us at a bad time with this request, where makepanda and Panda have changed substantially in the build process, and the cvs build is in flux.

David

Alright, my goal right now is to compile a working debug and release panda build, both using the same setup.

Here’s the error that stops me:

1>  Found extensions for class: EggPrimitive
1>  Found extensions for class: EggGroupNode
1>thirdparty/win-python/python.exe direct\src\showutil\pfreeze.py -o built/bin/runp3d.exe direct/src/showutil/runp3d.py
1>Traceback (most recent call last):
1>  File "direct\src\showutil\pfreeze.py", line 116, in <module>
1>    freezer.done(compileToExe = compileToExe)
1>  File "C:\Panda3D-1.6.2_Source\built\direct\..\..\direct\src\showutil\FreezeTool.py", line 716, in done
1>    self.__loadModule(mdef)
1>  File "C:\Panda3D-1.6.2_Source\built\direct\..\..\direct\src\showutil\FreezeTool.py", line 779, in __loadModule
1>    self.mf.import_hook(mdef.moduleName)
1>  File "C:\Panda3D-1.6.2_Source\thirdparty\win-python\lib\modulefinder.py", line 124, in import_hook
1>    q, tail = self.find_head_package(parent, name)
1>  File "C:\Panda3D-1.6.2_Source\thirdparty\win-python\lib\modulefinder.py", line 178, in find_head_package
1>    raise ImportError, "No module named " + qname
1>ImportError: No module named direct/src/showutil/runp3d
1>Storing dependency cache.
1>Elapsed Time: 59 min 32 sec

Note: its worth mentioning I’m doing a release build which is what generated that error, I’m trying a debug build now, although I encountered an error because a file from ‘built’ (a release build directory) was missing.

Hmm, what happens if you just edit makepanda.py to no-op out FreezePy? I don’t think that you actually need this function to build a normal, working build; I think it’s necessary only if you plan to make an installer.

Edit line 902 of makepanda.py from:

def FreezePy(target, inputs, opts):
    assert len(inputs) > 0

To:

def FreezePy(target, inputs, opts):
    return
    assert len(inputs) > 0

David

Good news! I did that, and the compiled seemed to work! I even got my simple py tests and some samples (didn’t test all) to work!

Question is, how do I start debugging? Do I compile a C++ main() function and put breakpoints? When I run in MSVC it asks me which exe to attach the debugger, I choose ppython_d.exe but it says no symbols are loaded.

Note: I guess its worth mentioning I’m using a debug version of python that pro-rsoft compiled. But it seemed to work for Fenrir…

It appears that the version of Python that pro-rsoft compiled does not include debug symbols, but it links against the debug CRT.

Unless you plan on digging inside of the Python language interpreter itself, I wouldn’t be concerned about this. Just ignore the message.

As for starting the debug, setting break points into existing C++ code works just fine. You can do this before the program is running, or interrupt the program and then set them from there.

Good news indeed! Sorry about all the troubles getting a working build. We’ll have all of these issues sorted out by the time we release 1.7.

David

Sorry could you explain more? I’m actually novice at setting up the debugger in this kind of situation. Do I attach the debugger to a running process?

Also I made the first tutorial on loading an environment model and rotating the camera into a .dll linked against everything. However, the tutorial didn’t tell you how to load the compiled .dll with panda. Sorry if these are potentially obvious questions. I don’t have alot of time currently to spend problem solving, and I’m fairly new to python on this scale, whereas I am much more familiar with lua.

Edit:
Okay I just realized I’m supposed to compile it as a .exe not a .dll, hence the int main()… When I do that I get:

1>Linking...
1>MSVCRTD.lib(crtexew.obj) : error LNK2019: unresolved external symbol _WinMain@16 referenced in function ___tmainCRTStartup

Edit:
Okay solved that by recreating the project as a Win32 Console App rather a Win32 App. Aparently this configures the build properties differently.

I got the exe to work, debuging and breakpoints even!!! Haha, I’m very excited, the only issue is I have to copy the exe into the debug/bin/ folder so that it can find all the .dll needed. Is there a way to make it so I can run the exe from debug/gamename/built instead? (I’m guessing I just have to change ‘Additional Dependencies’ to …/…/bin/.lib instead of just *.lib so it looks in the right place, I will try tomarrow since it’s late)

All you should need to do is just point the MSVC project to your application start point, whether that’s a direct executable or python_d.exe with the parameter to start the appropriate Python module.

At that point, any breakpoints you have assigned anywhere in the Panda3d C++ code will be picked up, if everything is compiled properly.

You only need to attach to a running process if you want to debug in-situ. In the case of my original debug thread, I mentioned using that to hook into a running Panda3d/Python in order to do some rough debugging. You can do this anytime, and if a program has symbols built for it, you can even browse the running source. But since I was using a release Python and release Panda3d DLLS, things didn’t always quite match up. (As David had said in that thread, this occurs because any sort of optimization pass or mixing CRTs will make the symbols not exactly match what it expects in the pdb file.)

Well I was able to get it to work by compiling an exe to start panda rather a main.py type of set up, and just call the python file from C++.

I had already attempted what you mentioned, giving ppython_d.exe the location and name of the py file to start off execution. It would work if I ran from cmd prompt (the app would start fine), but form the debugger the console spewwed a bunch of text then closes. I will look into this more when I get home.

Edit:
Okay, when I run python_d.exe with my main.py script the following is spewwed just before the python cmd window terminates:

DirectStart: Starting the game.
:display(warning): Unable to load: Path not found
Known pipe types:
(all display modules loaded.)
...BIG STACK TRACE...
StandardError: No graphics pipe is available!
Your Config.prc file must name at least one valid panda display
library via load-display or aux-display.

Theres a huge stack trace from Direct Start, but it really doesn’t tell you anything important. I run this from the cmd prompt independant from MSVC and get the same error. Here’s my config.prc file:


load-display pandagl
#load-display pandadx9
#load-display pandadx8
#load-display tinydisplay

Could it be something with my version of python_d.exe? I also tried ppython_d.exe. If I compile a simple c++ file into an exe to open a window and use that, everything works.

P.S. I ran pview.exe with no issues.

It sounds like it’s either not reading your Config.prc file properly, or it’s not reading the plugin-path variable, and therefore can’t find libpandagl_d.dll etc.

Try setting plugin-path in your Config.prc file to the directory that contains libpandagl_d.dll.

If that doesn’t change anything, do this:

python_d
>>> from pandac.PandaModules import *
>>> cpMgr = ConfigPageManager.getGlobalPtr()
>>> print cpMgr
(prints the prc files loaded)
>>> print ConfigVariableSearchPath('plugin-path')
(prints the search path for dll files)
>>> print ConfigVariableString('load-display')
(prints the current setting for load-display)

Edit: ah, I just realized what the problem is. The makepanda version of Panda uses the location of libp3dtool.dll to figure out where the Config.prc file resides. With a debug version, it’s looking for the wrong dll name, and can’t find libp3dtool.dll (because that’s not in the memory space), so it fails to locate the Config.prc directory properly.

I’ve just checked in a fix. Pick up the latest dtool/src/dtooutil/executionEnvironment.cxx, and it should address this problem.

David

Thank you very much David, without you I’d still be lost. I’m compiling now, I’ll tell you how it goes when it finishes. I’m very eager to start development and the learning process with panda.

P.S. Updating that file caused makepanda to rebuild most of the libraries in bin/, is there a faster way for me to rebuild only whats needed or is this what must be done?

Hmm, I don’t really know why makepanda wanted to rebuild everything. It should have been necessary to rebuild only executionEnvironment.obj, and libp3dtool_d.dll. That sounds like a minor bug in makepanda.

David

Well, it seems like its a slightly more significant bug, considering it fired off an hour long build. What if I made modifications to one source file and want to test changes? Is there something I can do to just rebuild one library?

I would help with correcting makepanda.py if it wasn’t so long of a script, and if I had more knowledge of compiler options.

It’s a long script, sure, but it’s a long script of the form of “do this, then do this, then do this, then do this.” Structurally, it’s really extremely simple. And I don’t think you need to understand much about compiler options in order to understand how makepanda works. I bet you could figure out makepanda pretty well if you tried. :slight_smile:

Still, you did update a fairly low-level file–dtool is at the very bottom of the chain–and if it had been an .h or an .I file, you would have had to rebuild everything. This was a special case because you updated a low-level .cxx file only, which should not have required much in the way of rebuilding. In the more general case, though, you would be modifying .h files and .cxx files together, and they are more likely to be higher-level files, so in the big picture this may still not be that important a bug.

Furthermore, if you are really serious about getting into heavy-duty C++ development with Panda’s internals, you will probably be well-served to migrate to the ppremake build system instead. That build system is better able to handle these kind of changes. Really, makepanda is primarily targeted at people who are still new to Panda, and people who just want to build a plain-vanilla, unmodified Panda out of the box.

David

1.7 on Ubuntu Jaunty:
the /models shipped with panda is not listed in model paths.

Is it just me ?

I will learn ppremake then, but only when I have a need to start modifying core panda3d libraries. For the time being I need to get a basic understanding of whats currently possible, what I have to learn, ect. Now I’m in learning mode and won’t be able to develope anything serious for a while… as sad as it is to admit.

Are you doing what I did and building a debug version of panda? If you do a full CVS pull from the head revision for each folder (I had to do each folder since I don’t know how to do it all in one command). Models will be in the debug output folder when you build default is …/debug/models/.

Came back from vacation today and just noticed this thread. I’m sorry that you had to go through all these problems without me. :slight_smile:

I’m considering shipping a debug build for future releases.