interrogate2swig.py

Compiling or Editing the Panda Source
8

Ok, that’s cool.

Yes, there’s a nested class in panda/src/downloader/downloadDB.h, but luckily I dont think this is a really critical class for getting Panda running and checking the core is working ok?

Progress update

  • swig runs to completion with no errors, for both pandaexpress and panda
  • the swig-generated .cxx file compiles now! :smiley:
  • and the libpanda.dll link has run to completion

Timings

Swig: ~30 seconds
Compiling Swig output: ~1-2 minutes

Current methodology

interrogate function in makepanda.py rewritten to do simply:

  • run each header file through the preprocessor
  • add all the information it received as arguments to an xml file “swiginfo.xml”
  • swiginfo is a set of elements, each of which has a modulename, a libraryname, and a list of headerfiles
  • we also store a list of defines and include paths in swiginfo just in case that might be useful.

interrogatemodule function modified:

  • just a placeholder for now; returns immediately

new function GenerateSwigFile created:

  • closes swiginfofile, appending to the end first to close the document element
  • calls interrogate2swig.py, passing in the module name, and the path to swiginfo.xml
  • interrogate2swig.py will read all the information from swiginfo.xml corresponding to that module, and generate the sorted swig interface file; basically the code from above
  • back in makepanda.py, swig will be executed on this interface file to generate the appropriate .cxx file, and also the .py file

We call GenerateSwigFile just before linking libpandaexpress.dll and libpanda.dll, then we compile the resulting .cxx, and ensure this is in the list of objects to link for that dll.

Observations

  • preprocessing the headerfiles makes things a lot easier
  • we could probably just preprocess them in one go, rather than one by one; but doing them one by one doesnt take really long (5-10 minutes)
  • defining CPPPARSER during the preprocessing is essential, because it maps PUBLISHED: to __published:, rather than to public:, which we can detect in interrogate2swig.py
  • swig doesnt really understand inherited, nested enums, so the script replaces EnumName by ClassName::EnumName where applicable
  • we skip any file that use templates, because (i) swig doesnt like them too much and (ii) the interface published to Python is pretty-much template-free anyway

Overall, its looking promising, but I’m anticipating a few new issues when I actually try using the resulting python file in a few minutes.

Hugh