On 06/05/2009 12:46 PM, David Humphrey wrote:
* I've written jshydra to get me the js xpcom info needed to tell you
that nsIFoo is implemented by c++ and js. However, I cannot figure out
the best way to drive this code. I need to preprocess all the .js in the
tree before handing it to jsyhdra. I thought to use flat chrome, or just
get things out of jar files. But then I lose the source locations I
need. I really need a way to be able to process each .js file in place
in the tree.
I see two simple-ish solutions:
1) Modify the preprocessor to log a concise line mapping (naming the
output based on the filename of the dude being preprocessed) when it
sees an environment variable. It's in the tree, and is written in
Python. Easy peasy, except for the part that last time I had to deal
with this stuff there was still a perl preprocessor in use in some
cases. Hopefully that's no longer an issue:
http://mxr.mozilla.org/mozilla-central/source/config/Preprocessor.py
This requires minor modifications to the tree, but is simpler than the
alternatives. For example, in pecobro ( blog posts:
http://www.visophyte.org/blog/tag/pecobro/ repo:
http://hg.mozilla.org/users/bugmail_asutherland.org/pecobro/ ) I ended
up implementing a limited make parser/grokker so that I could collect up
all the DEFINEs that were passed to the preprocessing code. I also
implemented a (limited) jar manifest parser (primarily for chrome path
resolution to be able to resolve DTD references in XBL, but also) to
help me figure out what code was actually interest/live. By just
instrumenting and looking for the side effects of preprocessing, you
could get both of those for free.
(Given that pecobro was focused around a more dynamic understanding of
the system, there were also other benefits to some of that overkill,
although I'd probably do a lot of things differently today.)
2) Only process the preprocessed code. Preprocessed javascript code is
largely a dumb idea and there is almost no good reason for it. There is
no need to cater to that usage, and this will encourage people to
abandon it.
Andrew
_______________________________________________
dev-static-analysis mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-static-analysis
