ppremake dependency checks

Compiling or Editing the Panda Source
1

Hi All,

Does ppremake do any dependency checking?

I was having a terrible time building panda with ppremake. I read the docs
and at first the only thing I put in my Config.pp was to have it point at my python includes.

Started getting errors while building dtools about prtypes.h. Google
searched and that seemed to be Mac related ( I am running
Slackware Linux 10.1). Added…

#define BUILT_TYPE unix

… to Config.pp and it fixed that problem. I was then able to build dtools.

Anybody here of this before? Am I incorrect in the understanding that
you only put what is specific about your system in the top level Config.pp?

Anyway went to build panda without NSPR (see previous post) and started
getting CG compile errors about pthreads. “#defined HAVE_CG” to nothing
and got CGGL errors about pthreads! “#defined HAVE_CGGL to nothing” and
I still got errors about pthreads!.

I was doing make cleans, going back to dtools, running make clean, ppremake, make, make install before returning to panda and doing
ppremake, each time I edited Config.pp.

Still make was giving me these errors.

Looking back, I probably should have added “#define HAVE_NSPR” to my
Config.pp but I think I was expecting some kind of dependency check.

I mean if you need NSPR for threads, and you don’t have NSPR, and if CG and
CGGL need threads, then why was ppremake trying to build them? Does ppremake do dependency checking like make?

Anyway I couldn’t figure out how to install NSPR “system-wide” so I just put
it next to panda3d and edited Config.pp to point to it like David suggested.
Got all the way through the build system. Everything working fine!

So do you all think I have found a bug? I wonder if anyone else has had similar
problems?

Thanks,
Robert

B.T.W. What do you all call it when you undefine something by “#define”- ing
it to null? ppremake syntax makes my brain hurt. Talking about it makes
it hurt worse! :slight_smile:

2

ppremake does attempt to do some limited automatic dependency checking, but it can make mistakes. For instance, if it finds libnspr4.so in your system library path, it assumes NSPR is installed but in fact the API might not be.

Also, there are some unintended dependencies between modules that developers may not be aware of when they add support into Panda3D. For instance, the developer who added support for CG probably didn’t realize that this also added a dependency on threading, which really means the resulting executable needs to be explicitly linked with the system threading libraries–but linking with NSPR also solves this problem. Since it’s difficult to regression-test Panda3D with every possible combination of optional modules, it’s difficult to discover mistakes like this.

For the most part ppremake relies on the programmer to configure the build properly. It could be made more automatic, but to correctly diagnose every possible combination of build configuration on every possible build environment–including Windows environments–is a challenge worthy of a project all to itself.

The file prtypes.h is actually a part of NSPR. Usually when the compiler complains about not finding prtypes.h, it is because ppremake has incorrectly concluded that you have NSPR installed, possibly because of the libnspr4.so bug I referenced above. Since this has burned a couple of people on different occasions, it would probably be prudent for us to fix this particular bug sooner rather than later (I do apologize for the difficulty it caused you).

Of course, all this must be balanced against the expected lifespan of the ppremake build system. It is still the most versatile and flexible way to build Panda, but it is complex and error-prone, and eventually we hope to completely replace it with the makepanda system. So we have to balance the value of fixing bugs in ppremake vs. improving the power and flexibility of makepanda.

Congratulations for getting your build successfully completed!

David