LXR/MXR

So I have played around with the Mozilla cross reference tools and found them to be very useful. The only issue I really had was that when you click on a link within the source code it performs a global search on that term and often times the results are out of context - especially when the term is a common member/method name within a number of different and unrelated classes. I have to admit though that searching for a specific function in the code (in my case the code that controls the refresh button) only made the work thats a head of me and Brandon seem even more daunting (though we are gaining new appreciation for large software as we go along). We already spent a couple of hours trying to figure out where our code would need to go and found some classes which we are hoping would come in useful - although by no means can we say that we have a clear grasp of how plugins operate within Firefox as of yet. We are meeting up this Wednesday to do some more digging and we are also going to be adding our own code, mainly some printfs to try and orientate ourselves within the source. Updates are to follow.

Firefox 3 built on Windows and Fedora (about 8 times faster)

So I have figured out what was my problem with building Firefox... as Ted Mielczarek pointed out I was changing the .mozconfig.mk file within the Mozilla directory thinking thats the configuration file when in fact it is actually .mozconfig without the .mk extension as .mozconfig.mk is auto generated by the build script (which would also explain why it was overwriting the file each time I ran the build command).

In any case I fixed that and then ran the build command once again. It started the build and after 9 very long hours (yes 9 hours) it told me that there were errors so it aborted the compilation. So what I did was create a new folder on my C drive then I re-downloaded the client.mk file and then checked out the code once again. I then created a .mozconfig file and placed it in the Mozilla directory and ran the build command. 10 long hours later the build was complete and I had a running version of Minefield.

I'm now in the process of building on Fedora 7 which I installed on a virtual machine on my desktop. Hope it goes smoothly and will post an update when its done.

UPDATE:

The build on Fedora went fine... in fact I would say better than fine since it only took a little over 70 minutes. But what is strange about this is that both builds were done on the same hardware... the first being in Windows XP SP2 with 1GB of RAM and the second in Fedora 7 running inside XP on a virtual machine, with a mere 256MB of RAM -- a quarter of the memory that was available during the first build. Whats even stranger is that this was a debug enabled build where as the one on XP was not. Someone on IRC (andrew) was suggesting that this may be due to my anti virus software so if you haven't compiled Firefox yet you may want to consider shutting down your AV for the duration of the build when you get around to it.

Building Firefox

So I set out late this evening to try and build Firefox. I read a few of the blogs on the subject and decided to use Simon Jung's tutorial. Unfortunately however, I encountered an error that I could not correct. This is my output when I issue the following build command:

make -f client.mk build MOZ_CO_PROJECT=browser

In addition to the error I'm getting, my .mozconfig.mk file also keeps getting overwritten with the following version:

# gmake
# This file is automatically generated for client.mk.
# Do not edit. Edit /c/Documents and Settings/xRayon.AKDESKTOP/.mozconfig instead.
# To create a new .mozconfig file, you can visit,
# http://webtools.mozilla.org/build/config.cgi

# PATH=/local/bin:/c/mozilla-build//wget:/c/mozilla-build//7zip:/c/mozilla-build//blat261/full:/c/mozilla-build//python25:/c/mozilla-build//svn-win32-1.4.2/bin:/c/mozilla-build//upx203w:/c/mozilla-build//xemacs/XEmacs-21.4.19/i586-pc-win32:/c/mozilla-build//info-zip:/c/mozilla-build//nsis-2.22:.:/usr/local/bin:/mingw/bin:/bin:/c/Program Files/Microsoft Visual Studio 8/Common7/IDE:/c/Program Files/Microsoft Visual Studio 8/VC/BIN:/c/Program Files/Microsoft Visual Studio 8/Common7/Tools:/c/Program Files/Microsoft Visual Studio 8/Common7/Tools/bin:/c/Program Files/Microsoft Visual Studio 8/VC/PlatformSDK/bin:/c/Program Files/Microsoft Visual Studio 8/SDK/v2.0/bin:/c/WINDOWS/Microsoft.NET/Framework/v2.0.50727:/c/Program Files/Microsoft Visual Studio 8/VC/VCPackages:/c/WINDOWS/System32:/c/WINDOWS:/c/WINDOWS/System32/Wbem:/c/mozilla-build/moztools/bin

This happens every time I run the build (or clean) command. I have no idea what the error message at the end refers to or why the configuration file is getting overwritten but will be investigating it further tomorrow. The .mozconfig.mk file (/c/Documents and Settings/xRayon.AKDESKTOP/.mozconfig) the overwritten configuration file is refering to also doesnt exist by the way. Updates to follow.

Project selected!

So I have finally settled on a project for my OSD600 course. My choice - the Plugin-Watcher will, I imagine, involve delving deep into the core of the browser code. This will be a C/C++ heavy project and I chose it for a number of reasons; but I would first like to describe its purpose.

The What
Firefox, as you know, is used by millions of people worldwide. Each of them depends on its continuous reliability and stability.The issues faced by complex software such as Firefox in this arena are immense, particularly so in the case of browsers, since besides having to render HTML and execute JavaScript and the like they are also increasingly used as a host platform for various plugins and third party add ons - some of which have been badly written and/or poorly tested.

As the name implies the Plugin-Watcher will track all installed plugins and make certain that non of them are impairing the browser itself. In the event that a plugin misbehaves by either slowing down or making Firefox unresponsive the Plugin-Watcher will notify the user that something has gone wrong with one of the installed plugins. Me and my partner Brandon are hoping that by the final release (at the end of OSD600) the watcher would also be able to identify to the user the actual plugin thats misbehaving and perhaps provide options such as disabling that plugin.

The Why
I chose this project because it meant that I would have to work with the actual guts of the browser. I'm really hoping that through this experience I will gain a greater understanding and a deeper appreciation for Firefox and open source software in general. This is also a C/C++ project which I have to admit I'm more comfortable with than say JavaScript - same goes for my partner Brandon.


The How
We decided to use Visual Studio 2005 as our development platform. An odd choice perhaps considering we are dealing with an open source project, but we are familiar with the IDE and will certainly require its debugging tools. I'm also considering installing Linux on a virtual machine for testing purposes. I already have VMWare workstation installed and I'm downloading the Fedora 7 DVD as these words are being typed.