.in files

The online API reference does not support MAKE_SEQ functions nor does it support overloaded functions, so I thought I’d take a poke at adding support for those to gendocs.py.
It doesn’t appear to be so simple as it seemed though. Gendocs reads out interrogate’s .in files and parses the lines in there to generate the function definitions.
However, it looks like it’s interrogate’s .in files that are lacking the overloaded functions and MAKE_SEQ functions.
For example, in libpgraph.in, I can only find one NodePath::set_texture entry, and no PandaNode::get_children entries at all.

Can somebody fill me in about this? What exactly is the purpose of the .in files and why do they lack these functions, even though they are available in the resulting libraries?

Back before interrogate generated full Python object class wrappers, when it was only generating C-style function wrappers around each method and it require a Python module called ffi to generate the actual class wrappers (similar to the SWIG model), the .in files were an essential part of this process. Interrogate would generate a .cxx file that compiled into a table of C-style function wrappers, and an .in file that described the relationship of all of these functions to their classes. The ffi module would read the .in file and use that information to generate the class wrappers.

Nowadays, the .in files are largely vestigial, since interrogate does all the work itself and compiles full class objects into the .cxx file. So, when I added the MAKE_SEQ support to interrogate, I didn’t think about adding the generated functions to the .in file–I forgot that the online API reference still reads the .in file.

It’s on my list of things to go back and fix. If you’d like to do it sooner rather than later, you’re welcome to make the necessary changes to interrogate; but it is a pretty hard-to-read bit of code in there.


Thanks for the explanation. If I, hypothetically, would look into doing this, in which file would I start looking?

interfaceMakerPythonNative.cxx does most of the work of generating the C++ code, and I believe this is where the MAKE_SEQ() macros are expanded.

The .in files are called the “interrogate database” which is read and written by the code in the interrogatedb directory.