While James takes some time to get up to speed on Mozilla, MDC, MXR, and friends, I decided to take a detour from my front-end work on the MDRK to investigate the potential for using dehydra to replace parts of MXR's cross-reference code. Disclaimer: all that follows is the blathering of a fool with a powerful tool, but only partial understanding of how to use it.
Did you ever see War Games? Remember that part where they break into the war computer and he says, "you want to hear it talk?" Well, dehydra is what gcc would sound like if you could hear it chewing-up your source files and spitting out object files. It eats cpp for breakfast, literally--it's a plugin for gcc, so for every file gcc compiles gets processed secondarily by dehydra.
What you do is specify a script to be run by dehydra for each file that gets compiled. This being Mozilla you know that the script is written in js, which is great. Your script defines callbacks, much like a SAX stream parser or similar, and you get to deal with the abstract syntax tree (AST) nodes as they zoom by.
After getting a working dehydra built and setup in Linux, I successfully reproduced Taras' count_classes.js example from his blog. That provided me a jumping-off point for writing my own scripts. I modified his code to print info about classes vs. just their name, which was a good way to learn how to work the dehydra js API. After a successful run (~24 mins) of my build + script I have an objdir filled with .o files (as usual) and also text files with my class data.
With a few minor successes under my belt, I moved on to try and solve Dave Mandelin's challenge from his blog. I found this harder, since it meant processing the internals of each function, and the way the js API is structured, properties are not there if not applicable, but it's not always clear to me what I'm dealing with (i.e., what the node I have right now really is). Lots of stumbling in the dark and I think I have it, such that I can see that:
privatePrevAccessible->SetParent(this);
is really:
nsPIAccessible::SetParent(nsIAccessible*)
except that's not quite right. At runtime it's going to be some concrete type, and I need to know what that is, or could be. I spent the better part of an hour fumbling with the various combinations and permutations of node properties and attributes, trying to get at concrete types from my interface. Then, after taking a break to cook dinner, it became clear that I was misunderstanding what Dave had meant by "Dehydra knows the class hiearchy, so it can find all the concrete classes that that variable can be, and all the SetParent methods those classes have." For purposes of testing my scripts, I'd been doing incremental builds of nsHTMLImageAccessible.cpp, and to solve my problem I need to aggregate what dehydra knows for the whole tree first.
After emailing Dave for advice, I realized that it might make sense to spit out .sql scripts for each compilation file and then use them to create a database (SQLite, which Firefox can also consume -- you see where I'm going?) with all the type/member/function/etc info I need in order to do queries about types after the fact.
At least that's my thinking for tomorrow. Hopefully Dave will email and set me straight if I'm getting off the rails. At any rate, I'm having fun and learning a ton.
UPDATE: Chris thinks I need a data-only format vs. sql files to generate the database. The fact that I'm basically producing text files means I can make whatever I want.