There’s no way to clean an existing source tree?
After running makepanda, all the files are in the “built” subdirectory. If you remove the entire directory, then you’re back to a clean source tree.
After running ppremake, there’s a “make clean,” but I know it doesn’t delete everything. I have this vague recollection that there’s also a “make veryclean” or something along those lines — I can’t speak authoritatively about that.
i was hoping that there would be some more progress with getting panda3d compiled on os x. i gave it a shot with the 1.0.4 version and i’ve found:
-
having two custom methods to compile is confusing and presents a steep learning curve. (e.g. which one is recommended? is makepanda.py newer? also, the first step with ppremake should be “compile ppremake”!)
-
makepanda.py: “cp --recursive” doesn’t work. need “cp -R” instead
-
makepanda.py: checks if sys.platform is “win32” or “linux”. if we are “darwin” then variables aren’t defined, and it barfs.
-
#include <malloc.h> doesn’t exist on freebsd/OS X.
-
direct/src/directbase/ppython.cxx: all the code is commented out if we are not WIN32 or linux which gives a _main() is not defined error.
i’m sure the OS x people could supply some simple patches here, but it seesm that there needs to be a bit more direction from the package maintainers as to how to handle multiple platforms. currently, it seems the limit of the if windows else (linux) system has been reached! 
I’ve been through all those things and patched 'em up… just keep hitting obstacle after obstacle. I guess I’ll get around to properly cleaning my source dir and trying again at some point…
For the makepanda just add another line:
elif sys.platform == ‘darwin’:
#linux settings
Macs are similar to linux (i.e both use gcc etc)
Of course you only get a little further. 
I just wanted to point out in case anyone is having difficulty with this code snippet, it should probably be
#undef OLD_STYLE_ALLOCATOR
#undef GNU_STYLE_ALLOCATOR
#undef VC6_STYLE_ALLOCATOR
#undef MODERN_STYLE_ALLOCATOR
#define NO_STYLE_ALLOCATOR 1The c preprocessor strikes again!
Has any progress been made on a Mac port?
Malcolm
Greetings all!
Now that the 1.1.0 version of the Linux port seems to be semi-stable (see https://discourse.panda3d.org/viewtopic.php?t=977), I’ve begun trying to pull the Linux version over to Mac OS X.
So far, it’s going pretty well! I’ve used the comments and information provided on this forum thread to sidestep some of the early hurdles. I now have an interrogate binary at built/bin/interrogate, but it’s giving me a bit of difficulty when I give it a test-run. I’m very new to the interrogate tool, so I was hoping someone could give a bit of guidance concerning how to attack the following error message:
built/bin/interrogate -srcdir panda/src/express -DCPPPARSER -D__STDC__=1 -D__cplusplus -D__ppc__ -D__const=const -Sbuilt/include/parser-inc -S/usr/include -Ibuilt/python/include -Ithirdparty/linux-libs-a/zlib/include -oc built/tmp/libexpress_igate.cxx -od built/pandac/input/libexpress.in -fnames -string -refcount -assert -python-native -Ibuilt/tmp -Ipanda/src/express -Ibuilt/include -DBUILDING_PANDAEXPRESS -module pandaexpress -library libexpress atomicAdjust.h atomicAdjustDummyImpl.h atomicAdjustImpl.h atomicAdjustNsprImpl.h bigEndian.h buffer.h checksumHashGenerator.h circBuffer.h clockObject.h conditionVar.h conditionVarDummyImpl.h conditionVarImpl.h conditionVarNsprImpl.h config_express.h datagram.h datagramGenerator.h datagramIterator.h datagramSink.h dcast.h encryptStream.h encryptStreamBuf.h error_utils.h express_headers.h externalThread.h hashGeneratorBase.h hashVal.h indirectLess.h littleEndian.h mainThread.h memoryInfo.h memoryUsage.h memoryUsagePointerCounts.h memoryUsagePointers.h multifile.h mutexDummyImpl.h mutexHolder.h mutexImpl.h mutexNsprImpl.h namable.h nativeNumericData.h numeric_types.h ordered_vector.h password_hash.h patchfile.h pmutex.h pointerTo.h pointerToArray.h pointerToBase.h pointerToVoid.h profileTimer.h pta_uchar.h ramfile.h reMutex.h reMutexHolder.h referenceCount.h reversedNumericData.h selectThreadImpl.h streamReader.h streamWriter.h stringDecoder.h subStream.h subStreamBuf.h textEncoder.h thread.h threadDummyImpl.h threadImpl.h threadNsprImpl.h threadPriority.h tokenBoard.h trueClock.h typedReferenceCount.h typedef.h unicodeLatinMap.h vector_uchar.h virtualFile.h virtualFileComposite.h virtualFileList.h virtualFileMount.h virtualFileMountMultifile.h virtualFileMountSystem.h virtualFileSimple.h virtualFileSystem.h weakPointerTo.h weakPointerToBase.h weakPointerToVoid.h weakReferenceList.h windowsRegistry.h zStream.h zStreamBuf.h express_composite1.cxx express_composite2.cxx
*** Error in /usr/include/libkern/machine/OSByteOrder.h near line 50, column 14:
parse error, expecting `')''
Error parsing file: 'atomicAdjust.h'
Elapsed Time: 11 secNote that I did change the architecture definition line from i386 to ppc, since that seemed to follow the pattern of the other architectures. Looking over the offending line in OSByteOrder.h, I don’t see any problems inherent to the line itself. Can anyone give any suggestions on this issue?
One other issue is the third-party binaries. I’ve created a directory named thirdparty/darwin-libs-a that I plan to populate following the pattern of the thirdparty/linux-libs-a directory. I’m a little hung up on the NSPR components right now. Josh left a README note (bonus points for proper documentation!) that mentions the original compilation unit was modified—specifically, that LIBRARY_NAME was changed to avoid namespace conflicts. I snagged a copy of NSPR’s sources off of Netscape’s website, but I wasn’t able to find a LIBRARY_NAME key in the source. Would it be possible to obtain a copy of the modified source that was used to build the instance of nspr in linux-libs-a?
Thank you for all your help!
This is a system include… suprising it is even trying to parse it , May be becouse the inlined function has a structure in it … hmm
Easiest way I gnow of to get by this is to add a
ignorefile OSByteOrder.h
to an .N file… Quick look at interigate.cxx and such will put you on the right track.
Another quick trick that we often do is to add a stubbed-out copy of this header file to dtool/src/parser-inc directory (and add a rule to the build script to install this header file to include/parser-inc).
This parser-inc directory is only scanned when running interrogate, no actual compiler ever pulls header files out of this directory. If you look in there, you’ll see lots of stubbed out header files, including things like windows.h and rand.h.
The advantage to using a stubbed-out file is that you don’t have to put a .N for it in every directory that might include OSByteOrder.h, and you can also put some typedefs in the stub file that might be necessary to parse files that include OSByteOrder.h and expect certain types to have been defined. Note that the typedefs don’t necessarily have to be accurate; they usually just have to name the new type, it doesn’t matter what it’s typedeffed to.
David