Open main menu

CDOT Wiki β

Changes

Delta debugging framework

1,494 bytes added, 20:39, 17 October 2006
Project News
''This is where your regular updates will go. In these you should discuss the status or your work, your interactions with other members of the community (e.g., Seneca and Mozilla), problems you have encountered, etc. Put detailed technical information into the Project Details page (i.e., update it as you go), and save this section for news about participation in the project.''
 
'''Oct. 17, 2006'''
 
The quest to build a suitable "wrapper" for the build system is not doing well. So far I have only observed various build logs posted on [http://tinderbox.mozilla.org Tinderbox] for the SeaMonkey build. Here are some observations I come up with.
* Successful builds - green or yellow on Tinderbox
 
<pre>
seamonkey-bin exists, is nonzero, and executable.
seamonkey-bin exists, is nonzero, and executable.
seamonkey-bin binary exists, build successful.
</pre>
 
* Broken builds - red on Tinderbox
 
<pre>
gmake[6]: *** [nsAttrValue.o] Error 1
...
gmake: *** [alldep] Error 2
</pre>
 
Analyzing build logs may be the "lazy" solution to building a wrapper to detect build failures, but that's the best thing we've got so far. Searches for any of the strings listed above in LXR did not yield valuable result, which means the build system remains a mystery to us. Thoughts:
* Tinderbox builds rely on report logs to capture build data. If we can figure out how to get tap into this process, we can better plan our prototype.
* Tinderbox performs a build operation first, and then automatically starts a bunch of tests (e.g. MozillaAliveTest, regxpcom test). These tests do not exist within LXR, either, which means they reside outside the tree. If we can find the script that fires these tests, we can probably create our first prototype as a test and hook it into the build system.
So many questions... Perhaps I should start hanging out at [irc://irc.mozilla.org/build #build].
'''Oct. 15, 2006'''
1
edit