Metalibs?

I’ve been doing a lot of work on makepanda and the Panda build process, and one thing I’ve just not been able to figure out is the meaning of “metalib”.

Can anyone give me a definition of “metalib” as used by Panda? All of the theories I’ve come up with so far don’t quite seem to fit the actual usage.

–jonah

The concept of “metalib” was introduced when we originally migrated the build system from Linux to Windows. The original build system created a single shared library for each directory within the panda/src tree, so there was a libpgraph.so, libputil.so, libgobj.so, and so on.

When we moved to Windows, we discovered that that level of modularity wouldn’t work with MSVC (and particularly with Microsoft’s implementation of STL), so we had to combine multiple directories together into a few big DLL’s. So we ended up with libpanda.dll, libpandaegg.dll, and so on. We called these files “metalibs”, because they were collections of smaller libs packaged into a single big lib.

Nowadays makepanda builds everything into these metalib files on every platform. If you use ppremake, it still builds individual libs on Linux and Mac, and it builds metalibs on Windows.

David

Thanks for the insight, David. My theories were mostly along those lines, except that there are a couple of libraries that don’t fit the mould. For instance there’s a “pandabullet” single-directory metalib, while “pandaskel” is built from code in a single directory but isn’t a metalib, and “p3direct” which is a metalib built from code in multiple directories but isn’t named with the “panda” prefix. My best guess on all of these was that the implementors of those packages (and a handful of others) weren’t aware of the established usage pattern. Is that a reasonable explanation, or is there something deeper going on I’m not yet grocking?

–jonah

pandabullet and pandaskel had no need for multiple directories (all of their code was already in a single directory), so they were never “metalibs” in the same sense. I suppose there have been differences of opinions as to whether they should follow the metalibs conventions anyway (the developer of pandabullet decided one way, while the developer of pandaskel decided the other).

libp3direct.dll was originally named libdirect.dll, because it is the code in the “direct” tree, as opposed to the code in the “panda” tree. We later added the p3 prefix when we added this prefix to all dll’s that weren’t already named “panda”.

David