Fissioning libpanda.dll

Compiling or Editing the Panda Source
1

How easy would it be to fission libpanda.dll? What are the issues involved?

The advantage would be:

  • faster building (a single libpanda.dll link uses a lot of memory)
  • more modular

The potential issues would seem to be:

  • something to do with exporting templates?

Looking at libpanda.dll, right now it has:

  • core graphics classes (geoms, pandanode)
  • linmath core
  • parametric node derivatives (optional)
  • text nodes (optional, needs FreeType)
  • collision engine (optional)
  • audio (optional)
  • gui (optional)
  • lerp (optional?)
  • egg model processing and nodes (core? optional?)
  • event classes (core(?))
  • pstatclient (optional(?))
  • devices, dgraph (core)
  • recorder (optional)
  • pnmimages (optional)

Could it be interesting to break these up into dlls as follows:

  • core: core graphics classes, devices, dgraph, event classes, linmath
  • pnmimages
  • recorder
  • audio
  • parametric nodes
  • text nodes
  • collision engine
  • pstat client

What do you think? How do template classes affect this?

Hugh

2

This has been on my todo list for a while now.

There are, as you point out, several advantages to having many separate DLL’s instead of one big monolithic DLL. In fact, this is the original way Panda was designed to compile, with each module–that is, each directory–as its own DLL; and it is the way it still does compile on Unix/Linux.

The only real reason that libpanda.dll exists now is because VC6 required it (see https://discourse.panda3d.org/viewtopic.php?t=392). Presumably, that is no longer an issue on VC7, although we haven’t tested this. I’m not sure whether it’s still important for us to support VC6; I haven’t heard from people trying to build Panda with VC6 in over a year.

However, there are other advantages to having just one (or only a few) DLL’s, particularly when shipping a product. Specifically: there is less code bloat due to templates (they are more likely to be collapsed together); load time is shorter; there is less risk of name-collision with some other DLL with on the user’s machine.

It would be nice if Panda’s build system allowed us to build in either mode: separate or composite. The developer wants to work with a separate build, since it’s much more convenient for development; but you want to have a composite build when you’re ready to ship your product.

(Actually, as long as I’m dreaming, maybe Panda’s build system could even allow you to specify the exact subset of modules you would like to be coalesced into a single DLL; and you could specify any configuration of n DLL’s and m modules. That would be nice. Sure sounds like a complicated build system, though, and there are good reasons to prefer a simple build system.)

To answer your original question in a practical manner, mostly what we’d need to do to achieve a separate build on Windows is to modify the build scripts appropriately. We’d also need to expand on the EXPCL_PANDA system; presently, we have a different EXPCL_* symbol for each DLL. We’d have to expand this list so that we have a different symbol for each module (e.g. EXPCL_TEXT, EXPCL_GOBJ, etc.), and then use some clever #defines to map each module symbol to its containing DLL at compile time.

David

3

Given that the Microsoft .Net compiler is free, and freely available, this is possibly sufficient justification for ditching explict vc6 support?

Hugh

4

Yes; it sounds like a fine argument to me. The only issue then is the inertia–someone has to do it. :slight_smile:

David