I’m attempting to sanity-check my Panda3D build environment for version 1.1.0 by running makepanda/makepanda.py --nothing under Debian (kernel version 2.4.27-2-386, python version 2.3.5). When I run the makepanda script, I get the following error:
Regenerating file: built/tmp/dtool_have_flex.dat
Regenerating file: built/tmp/dtool_have_pandatool.dat
Regenerating file: built/tmp/dtool_have_pandaapp.dat
Regenerating file: built/include/dtool_config.h
Generating dependencies...
Traceback (most recent call last):
File "makepanda/makepanda.py", line 1985, in ?
EnqueueBison(ipath=IPATH, opts=OPTS, pre='cppyy', src='cppBison.yxx', dsth='cppBison.h', obj='cppParser_cppBison.obj')
File "makepanda/makepanda.py", line 1064, in EnqueueBison
CopyFile("built/tmp/"+dstc, dir+"/"+dstc+".prebuilt")
UnboundLocalError: local variable 'dstc' referenced before assignment
I’ve looked at the source in question, and I don’t see how the ‘dstc’ variable is intended to be defined in this context. Is this a typo?
On a larger note: the sanity check is part of an attempt to port Panda3D to Mac OS X (step 0: make sure the source builds as expected on a known architecture). I’m attempting to use makepanda since it’s been used in previous attempts. I’ve read over the documentation for both makepanda and ppremake, and I’m torn on the issue of which system to use. Would I be likely to run into less hassle with ppremake, or is makepanda a better long-term road to follow?
Hmm, Josh will have to speak to the apparent typo. I suspect it may be a bit of code rot, or a paste-buffer corruption error.
Here’s the history of the two build systems. Originally, we had only the ppremake system. This was developed at the Disney VR Studios, and we still use it every day and keep it maintained. It is designed to be extremely flexible and customizable. However, it is also unfortunately poorly documented and quite confusing to the newcomer.
Josh implemented the makepanda system as part of the effort to make Panda easier to build for a newcomer. It’s marvelously self-contained and generally works well. However, it’s not as powerful as ppremake; in particular, it’s not yet powerful enough to build Panda according to the needs of the VR Studio, so we still use ppremake.
Ultimately, I’d like to move to just one build system for Panda; I think it’s confusing to have two unrelated build systems. This probably means we will eventually embrace makepanda and discard ppremake. But before that can happen, we will need to add a lot more flexibility into makepanda.
Short answer–maybe makepanda is the best choice to work with for now.
It’s almost certainly bit-rot. Somehow, you’ve triggered a rarely-used portion of makepanda. Unfortunately, I’m at my mom’s house, and I don’t have the ability to examine code from here (at least, until I install some software on her computer). I’ll do that later on and I’ll see what’s going on. Until then, you might want to take a look at the context in which this occurred. Makepanda is generally a lot of straight-line code that looks like this:
if (option):
compile this thing
if (option2)
compile that other thing
You might want to try to figure out what option triggered this problem.
Excellent suggestions; thank you for the crash-course in makepanda’s format!
I see the options to which you referred in the code-format overview. I’m currently running makepanda with the --nothing directive, so I should be following the “omit” codepaths, I believe.
It looks as though the problem I’m seeing may be that the EnqueueBison function suffered from an unfinished copy-paste; I think that instances of the “dstc” local variable in this function should instead be instances of the “src” local variable. I’ve made this change and I can now bypass the python script error I saw previously.
I’m now running into the following issue when I run makepanda.py with --nothing:
-------------------------------------------------------------------
Makepanda Initial Status Report
Makepanda: Compiler: LINUXA
Makepanda: Optimize: 3
Makepanda: Keep Pkg:
Makepanda: Omit Pkg: PYTHON ZLIB PNG JPEG TIFF VRPN FMOD NVIDIACG HELIX NSPR OPENSSL FREETYPE FFTW MILES MAYA5 MAYA6 MAYA65 MAX5 MAX6 MAX7 BISON FLEX OPENCV PANDATOOL PANDAAPP
Makepanda: DirectX SDK dir: None
Makepanda: Verbose vs. Quiet Level: 1
Makepanda: Don't generate API reference manual
Makepanda: Version ID: 1.1.0
Makepanda: Caution: the built/lib directory is not in LD_LIBRARY_PATH
Makepanda: or /etc/ld.so.conf. You must add it before using panda.
-------------------------------------------------------------------
Regenerating file: built/tmp/dtool_have_bison.dat
Generating dependencies...
Copying "dtool/src/cppparser/cppBison.yxx.prebuilt" --> "built/tmp/cppBison.yxx"
Elapsed Time: 0 sec
Cannot read dtool/src/cppparser/cppBison.yxx.prebuilt
I’m afraid I don’t see any file matching that filename in the repository, though I do see a cppBison.cxx.prebuilt. Could the directive be attempting to access this file instead of the .yxx file?
I should note that including the --use-bison directive does bypass this issue (although I get a similar one when I hit the lexer). Since the overall goal is to tackle the OS X port, I suspect it’d be best to figure out why building with the --nothing directive is choking first. On the other hand, I believe I can assume bison in Mac OS 10.4 (although I hear it may be an older version of bison by default… GNU bison 1.28 is what I see). Could I save time on getting a sanity-check build up by simply including the --with-bison directive, or should I continue to hammer at --nothing under Debian until that is solid?
try moving the source around a bit. It looks like the following sections got reversed. Heres a revised example of enqueuebison:
def EnqueueBison(ipath=0,opts=0,pre=0,obj=0,dsth=0,src=0):
if ((ipath==0)|(opts==0)|(pre==0)|(obj==0)|(dsth==0)|(src==0)):
exit(“syntax error in EnqueueBison directive”)
if (COMPILER==“MSVC7”):
wobj=“built/tmp/”+obj
fn = CompileBisonMSVC7
if (COMPILER==“LINUXA”):
wobj=“built/tmp/”+obj[:-4]+".o"
fn = CompileBisonLINUXA
if (SLAVEBUILD!=0) and (SLAVEBUILD!=wobj): return
ipath = [“built/tmp”] + ipath + [“built/include”]
fullsrc = CxxFindSource(src, ipath)
dstc=obj[:-4]+".cxx"
if (fullsrc == 0): exit("Cannot find source file "+src)
dstc=“built/tmp/”+dstc
dsth=“built/include/”+dsth
#this should come after the dstc definition and fullsrc check
if (OMIT.count(“BISON”)):
dir = os.path.dirname(fullsrc)
CopyFile(“built/tmp/”+dstc, dir+"/"+dstc+".prebuilt")
CopyFile(“built/tmp/”+dsth, dir+"/"+dsth+".prebuilt")
EnqueueCxx(ipath=ipath,opts=opts,obj=obj,src=dstc)
return()
Oh, also, I’m not sure what you were doing to solve the redefinition error originally, but it looks like you probably didn’t strip out the yxx and put cxx in. cxx.prebuilt is generated from the yxx file specifically for bison lacking builds. I think
Oh, also, I’m not sure what you were doing to solve the redefinition error originally, but it looks like you probably didn’t strip out the yxx and put cxx in. cxx.prebuilt is generated from the yxx file specifically for bison lacking builds. I think
Same problem as in the other thread. --no-nothing doesn’t work because ofa bison problem. Delete the built directory, and try again with --everything option instead.
Thanks for the heads-up on --nothing; I hadn’t seen the other thread where it was attempted. If that codepath itself is expected to be dead, I’ll avoid it for now.
I slapped in zpavlov’s suggestion for the code-reorganization, and that solved the undefined dstc issue. The missing cppBison.yxx.prebuilt file is still an issue along this codepath (and there is a parallel missing file if flex is omitted), but since --nothing is to be avoided, I’ve begun building using the command line --use-bison --use-flex, which has avoided this issue. I don’t have the thirdparty sources yet, so I will download them and try that method as well.
When I use the bison / flex option set described above, I’m seeing the following compile error (being a C++ error, this is the start of it; I’ve omitted the “and these are the three-hundred ways you’ve angered the compiler” part )
g++ -ftemplate-depth-30 -c -o built/tmp/prc_composite.o -Ibuilt/tmp -Idtool/src/prc -Ibuilt/include -O2 -DBUILDING_DTOOLCONFIG dtool/src/prc/prc_composite.cxx
g++ -ftemplate-depth-30 -c -o built/tmp/dconfig_composite.o -Ibuilt/tmp -Idtool/src/dconfig -Ibuilt/include -O2 -DBUILDING_DTOOLCONFIG dtool/src/dconfig/dconfig_composite.cxx
g++ -ftemplate-depth-30 -c -o built/tmp/interrogatedb_composite.o -Ibuilt/tmp -Idtool/src/interrogatedb -Ibuilt/include -O2 -DBUILDING_DTOOLCONFIG dtool/src/interrogatedb/interrogatedb_composite.cxx
In file included from dtool/src/interrogatedb/dtool_super_base.cxx:19,
from dtool/src/interrogatedb/interrogatedb_composite1.cxx:3,
from dtool/src/interrogatedb/interrogatedb_composite.cxx:1:
dtool/src/interrogatedb/py_panda.h:56:20: error: Python.h: No such file or directory
dtool/src/interrogatedb/py_panda.h:57:26: error: structmember.h: No such file or directory
I see Python.h was copied to the built/include directory, but it’s in a subdirectory “parser-inc.” Should that subdirectory be in the -I options, or should that file be one directory higher (or a third option I’m not thinking of right now)?
It’s late o’clock on the eastern seaboard, so I’ll try the --everything option in the morning. Ideally, I’d like to keep the build options stripped to a bare minimum, since the overall goal of this build is to verify the build script itself so that I can begin tackling Mac OS X (the fewer options enabled, the smaller the front-end headache on that project… at least in theory). So --nothing would be ideal, but --use-bison --use-flex would be acceptable.
I’d like to thank everyone for their help so far; it’s slow-going, but porting always is. There is definite progress here!
I don’t have the thirdparty sources yet, so I will download them and try that method as well.
Here’s the problem: when I wrote all those makepanda command-line options, most of them worked. But I don’t test them regularly, the only option I use myself is --everything. I can’t guarantee that any other command-line option will work.
My strong suggestion is that you download the thirdparty sources, then compile with --everything. I can guarantee you that particular option will compile smoothly all the way through. Then, once you’ve got it working, you can start to play with variants, omitting things that you don’t need.
I got the thirdparty sources and gave makepanda/makepanda.py --everything a try. It looks like some files may not be located where the compile process expects them to be:
g++ -ftemplate-depth-30 -c -o built/tmp/cppParser_composite.o -I"/usr/include/py
thon2.3" -Ithirdparty/linux-libs-a/nspr/include -Ibuilt/tmp -Idtool/src/cppparse
r -Ibuilt/include -O2 dtool/src/cppparser/cppParser_composite.cxx
ar cru built/tmp/libcppParser.a built/tmp/cppParser_composite.o built/tmp/cppPar
ser_cppBison.o
g++ -ftemplate-depth-30 -c -o built/tmp/prc_composite.o -I"/usr/include/python2.
3" -Ithirdparty/linux-libs-a/nspr/include -Ibuilt/tmp -Idtool/src/prc -Ibuilt/in
clude -O2 -DBUILDING_DTOOLCONFIG dtool/src/prc/prc_composite.cxx
In file included from dtool/src/prc/configPage.cxx:23,
from dtool/src/prc/prc_composite1.cxx:4,
from dtool/src/prc/prc_composite.cxx:1:
dtool/src/prc/prcKeyRegistry.h:31:25: openssl/evp.h: No such file or directory
The openssl/evp.h file is in built/include/parser-inc; it looks like the include paths specified for that compile compnent only descend as far as built/include. I tried adding built/include/parser-inc to the include line by modifying makepanda.py line 1024 (in EnqueueCxx), but that seems to break other segments of the build process.
This issue has me stumped, I’m afraid. Any further suggestions would be greatly appreciated!
So the problem you’re running into looks to be that --everything is defining HAVE_OPENSSL, but the third party tools don’t include openssl. Ugg.
So one way to temporarily solve this is to do --everything --no-openssl
You could also install OpenSSL and provide links to its includes
Speaking of which, the reason why the parser-inc includes the file is that for panda to include third party libraries, any parts used have to be stubbed to ensure that the interrogater won’t go and try to interrogate a third-party library. Adding those to the include could mess with linking or other things
I am also having problems compiling 1.1.0 under Debian. I just downloaded the complete source code tarball, unpacked it and tried running ‘makepanda.py --everything’. It starts going wrong here:
I suspect that you’ve previous built this on a machine with Python 2.4 installed, so it has found Python.h in /usr/include/python2.4 (which is in the -I list). Which copy of Python.h should it find?
Aha. Looking into makepanda.py, I see that you look in /usr/include for the various python directories in decreasing order. Unfortunately, /usr/include/python2.4 exists on my machine but doesn’t contain any files (why? I don’t know. I’m not the administrator). Commenting out the appropriate line overcomes the problem.
It sounds like Python 2.4 is not installed on your machine. Probably there should be a parameter in makepanda to point the build at some other version of Python that is installed, for instance Python 2.3 in your case. I guess it’s trying to auto-detect whether a particular version of Python is installed, by looking for the existence of the appropriate directory, but in the case of Debian that test is failing since the directory already exists, empty, even though that version of Python is not yet installed. A better test would probably be to look for /usr/include/python2.4/Python.h.
After downloading the latest changes from the CVS repository, I was able to get Panda3d to compile on Debian using the following config options:
makepanda/makepanda.py --no-openssl --no-vrpn
The program compiled and populated the built directory.
I’m now running through the samples provided with Panda3d to verify functionality. I’m seeing some difficulty with the DirectObject class. Any class that attempts to inherit from DirectObject is meeting the following roadblock:
DirectStart: Starting the game.
Warning: DirectNotify: category 'Interval' already exists
Known pipe types:
glxGraphicsPipe
(all display modules loaded.)
Traceback (most recent call last):
File "test2.py", line 6, in ?
class World(DirectObject):
TypeError: Error when calling the metaclass bases
module.__init__() takes at most 2 arguments (3 given)
This seems to happen in all cases where the construct
class World(DirectObject):
is used.
I’m attacking the problem with pdb, but I’m a little stumped. Any suggestions?
Actually, there are a lot of CMU example programs that don’t import DirectObject at all, but assume that it will be imported by something else that they imported earlier.
This used to work, because there was something that unintentionally imported DirectObject. I think it might have been in DirectGui.
But recently, someone has fixed this problem with DirectGui, so that it no longer magically imports DirectObject, and now many CMU example programs appear to be broken. They will need to have the import statement that Zac describes above added to them.
I should’ve been more clear in my original post: the example was based off of a stripped-down copy of GreetingCard.py. It looks like at the very least, GreetingCard.py and Basic-Tutorials–Lesson-1-Scene-Graph/Tut-Step-4-Load-System.py are afflicted. I can munge through and clean those up on my copy.
Given this state of affairs, I’m willing to call the Debian build-from-source process workable—at least, workable enough to move from step 0 to step 1 of the Bigger Plan ™. Mac OS X port, here we come!
)