David Humphrey wrote:
You can file that in our bugzilla under WebTools : DXR. I'm gearing up
for a bunch of work on DXR this summer, so if you find other things,
file those too.
Hi David,
Thank you for that answer, I just opened bug 559856 about this.
I just realized that the Dehydra API
https://developer.mozilla.org/En/Dehydra/Function_Reference just might
not allow to do what's needed here, write_file will overwrite the data
in the file, right ?
Even if it did an append, it would not be very effective to open/close
the file each time.
This being said, I'm now trying to use the latest version of the script
instead, so goind back to trying to understand it first, with some doc
missing :-)
I'm reading what Joshua propose to make the build process more generic.
I think a simpler approach could be a good first step already.
I think if the steps of clobbering the build, building, and nss fix-up
inside dxr/xref-scripts/build-xref.sh were moved to a separate script,
in many case one would just have to replace that script by a specific
version to use DXR with a non-Mozilla project.
So I intend to do that, but I don't really understand how the new things
that have been added WRT the documented version work :
- .macros file generation :
You say : hijack REPORT_BUILD so we can get a .macros file for every
.cpp file compiled.
And there is :
REPORT_BUILD=
'$(if $(filter %.cpp,$<),$(CXX) -dM -E $(COMPILE_CXXFLAGS) $< > $(subst
.o,.macros,$@) 2>&1,@echo $(notdir $<))'
Could you give some info ? Is that black magic introduced inside the
compilation rules of the makefile for each file ? Is each file
preprocessed again after having been compiled ?
- call graph generation :
The client.mk call defines :
DEHYDRA_PATH='/var/www/html/dxr/tools/gcc-dehydra/dehydra/gcc_treehydra.so'
DEHYDRA_MODULES="${DXRSCRIPTS}/dxr.js"
TREEHYDRA_MODULES="${DXRSCRIPTS}/callgraph/callgraph_static.js"
So actually it's now treehydra and not dehydra that's executed when
compiling the source ?
Treehydra receives the two script and executes both the dehydra and
the treehydra module ?
How does this work exactly ?
And I was wondering why CXXFLAGS was still defined inside
dxr-mozconfig, but I see now that the CXXFLAGS lines inside
dxr-mozconfig are both commented out ! So there's not used anymore, and
replaced by what's defined in the call to client.mk, right ? You should
remove them fully.
Last, I've been looking at http://scotland.proximity.on.ca/dxr/ and
well, the caller graph code seem still quite incomplete, maybe buggy
(yes, I know, I'm warned in the first page). I get an empty description
window on member functions which I expect should show the list of
callers ? The callers:type::member syntax works, but to be honest it's
not really usable.
_______________________________________________
dev-static-analysis mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-static-analysis