As to the Config.pp in the dtool folder I followed the instructions of the Install document and saved the orignal as a sample to use in creation of my own custom Config.pp. They are very similar, except for the changes that I stated earlier. As to the Config not being found when placed in the root directory, I would assume that setting PPREMAKE_CONFIG is not the only thing that needs to be done to point ppremake at the appropriate path. Is that path hard coded elseware? Anyway my custom config is being parsed.
I got the cl error fixed, thank you. Running vcvars32.bat worked just fine.
I have a new error code now upon running make within the dtool folder:
Code:
Windows requires that if any part of an application is compiled to use the debug versions of the runtime libraries, then all parts of it must use the same debug runtime libraries.
If you set the OPTIMIZE variable to 1 or 2, you are requesting that Panda be built to use the debug versions of the runtime libraries. To reduce the chance of accidentally linking this version of Panda with any libraries that are not compiled to use the debug versions (which would introduce strange and mysterious runtime crashes), we append _d to the filename of each generated library. It is the same convention followed by Python.
The precompiled version of Python provided at python.org is not built against the debug versions of the runtime libraries, and hence its library name is python22.lib (and python22.dll). In order to get the debug version, named python22_d.lib (and python22_d.dll), you must compile it yourself from the Python source. This is not difficult to do; Python provides a .sln file that generally does the right thing.
Alternatively, you can reset your OPTIMIZE variable to 3, which is the lowest setting that uses the non-debug runtime libraries, and is the usual recommended setting for developers of Panda. Panda is stable enough these days that there’s not much reason to choose OPTIMIZE 1 or 2 unless you are really doing some major rewriting in C++.
Thanks for the explaination. That makes total sense. I changed the OPTIMIZE variable to 3 and got through the first part of building dtool. make ran with no errors, however when I called make install, the following occured:
C:\Panda3d-src\dtool>make install
mkdir -p /c/Panda3d-src/include
mkdir: not found
make: *** [/c/Panda3d-src/include] Error 127
The include folder does exist. I do not know what make install is trying to do. Does this error have anything to do with the dtool_config.h file??
The directory does exist, but I’ll bet you haven’t told Cygwin how to find it. Since mkdir is a Cygwin command, and Cygwin doesn’t automatically follow Panda’s convention of interpreting a one-letter toplevel directory as a drive letter prefix, you have to mount all your drives explicitly:
Are you sure? “make” is a Cygwin command. The non-Cygwin make command is “nmake”.
Your BUILD_TYPE variable must be set to gmsvc, the Cygwin build style, since “mkdir -p /c/Panda3d-src/install” is a Cygwin-style mkdir command. If your BUILD_TYPE were set to nmake, the non-Cygwin build style, ppremake would have generated the command “md C:\Panda3d-src\install” instead, which is the equivalent Windows-style command.
Also, I don’t think we supported the non-Cygwin build at the time of the 2004-04-27 download, if you’re using that version.
The following is an excerpt from the Install document of the 2004-07-27 download.
*** Begin excerpt
HOW TO BUILD PANDA ON A WINDOWS SYSTEM, WITHOUT CYGWIN
Note: although Panda can be built without Cygwin, for the moment we
have dropped support for the Microsoft nmake program (which is not
really supported by Microsoft either). Thus, even though you do not
need to have all of Cygwin installed, you will need to have at least
GNU make, as well as a few associated tools. These programs are
available from Cygwin (make.exe, sh.exe, cp.exe, rm.exe); you can copy
these programs from someone who has installed Cygwin. You will also
need the support DLL, cygwin1.dll.
*** End excerpt
As we discussed before this comment is incorrect and nmake should work. However I assumed that the approach that this document described still worked as well. With that in mind I copied these programs (make.exe, ect.) mentioned above into my c:\Panda3d-src\bin
My BUILD_TYPE is set to gmsvc.
Is there a more current Install document? Or is there a way you can send me the one that you are looking at? mwigand@gmail.com
I apologize for the confusion. The comment is (mostly) correct for that version of Panda–the BUILD_TYPE nmake is not supported in that version, and you are not using it. In the latest version of Panda, which can be downloaded via anonymous CVS from SourceForge, the nmake build is supported, and it is possible to build Panda without having any Cygwin tools at all.
At the moment, with your BUILD_TYPE set to gmsvc, you are indeed building Panda using the Cygwin tools (make, sh, cp, etc.), even if you are not starting the build from a Cygwin shell. The comment is a little misleading about the extent to which you are or are not using Cygwin.
Because you are using the Cygwin tools, it is still necessary to use the Cygwin mount command, which I described above, to map /c to c:/.
Oh, and one additional point: it looks like you will need to add mkdir.exe to the list of programs to copy from an installed Cygwin source. Sorry about that!
Should we be using the most current Panda3d modules in the repositry or the latest source code release panda3d-2004-07-27.zip(which is what I grabbed initially)?
The compiled version that is released on the Panda3d website is panda3d-2004-10-13B.exe. Is this compiled version based on the source code within the panda3d-2004-07-27.zip?
It’s probably better to stick with the 2004-07-27 release for now, unless you really need something in the current version. The CVS version of Panda is in a constant state of flux, and is not even guaranteed to be compilable at any given moment (although it usually is).
The pre-compiled release available on the CMU website is based on CMU’s version of the Panda code, as of the indicated date. The CMU team integrates with the SourceForge tree from time to time by extracting directly from the CVS repository. Thus, the 2004-10-13 release is somewhat newer than the 2004-07-27 release. Also, there may (or may not) be some additional work done by the CMU team, which has not yet been integrated into the core Panda source available on SourceForge.
I think this is due to a bug in dtool, which you were lucky enough to reveal by using a newer version of NSPR than the versions we have compiled against in the past.
In dtool/Config.Win32.pp, there is a line something like this:
Horray the compile of panda worked… however, upon running pview I received the following error:
pview.exe - Entry Point Not Found
The procedure entry point
?r_copy_subgraph@PandaNode@@MBE?AV?$PointerTo@VPandaNode@@@AAV?$pmap@PAVPandaNode@ @PAV1@U?$less@PAVPandaNode@@@std@@@@Z could not be located in the dynamic link library libpanda.dll
Have you previously installed the precompiled Panda from the CMU installer on this machine? If so, you might be loading up the wrong version of libpanda.dll. Try uninstalling this if you have it installed, and then make sure there is only one libpanda.dll on your system.
Ok, this one is a little strange. We might need to do some detective work. queuedConnectionManager.h is part of the Panda source, and should have been installed into your install include directory (C:\Panda3d-src\include) as a result of make install, as long as both HAVE_NSPR and HAVE_NET were determined to be true by ppremake.
(1) Does C:\Panda3d-src\include\queuedConnectionManager.h exist?
(2) Do any files in C:\Panda3d-src\include exist?
(3) Are HAVE_NSPR and HAVE_NET both #defined in dtool/dtool_config.h, or is either one of them given with a #undef?
color=red Does C:\Panda3d-src\include\queuedConnectionManager.h exist?
No, However it .h in question is located in C:\Panda3d-src\panda\src\net
color=red Do any files in C:\Panda3d-src\include exist?
Yes, a whole slew of them.
color=red Are HAVE_NSPR and HAVE_NET both #defined in dtool/dtool_config.h, or is either one of them given with a #undef?
Yes: #define HAVE_NSPR /c/nspr-4.4.1/lib/libnspr4.lib #define HAVE_NET /c/nspr-4.4.1/lib/libnspr4.lib
[color=red]Does the above do anything? In particular, does it copy queuedConnectionManager.h to the right place?
Yes, it does move the following .h files(might be more, but these are the ones i noticed) to the appropriate folder:
queuedConnectionListener.h
queuedConnectionManager.h
queuedConnectionReader.h
queuedReturn.h
