Penelope Developer Page
Building Thunderbird
- Build Thunderbird. If you're a coder, go fetch and build Thunderbird. Start learning how it works.
Building Thunderbird 3.0 on Linux from CVS
These were the steps followed to build Thunderbird 3.0a from CVS on linux. These instructions assume an up to date linux machine. The machine I used is running Gentoo Linux 2006.1. More thunderbird linux build details can be found at [developer.mozilla.org]
- Create a new directory and cd into it
- cvs -d :pserver:anonymous:anonymous@cvs-mirror.mozilla.org:/cvsroot co mozilla/client.mk
- cvs -d :pserver:anonymous:anonymous@cvs-mirror.mozilla.org:/cvsroot co mozilla/mail/config/mozconfig
- cd mozilla
- make -f client.mk checkout MOZ_CO_PROJECT=mail
- Create ~/.mozconfig with:
. $topsrcdir/mail/config/mozconfig ac_add_options --enable-default-toolkit=gtk2 ac_add_options --enable-xft ac_add_options --disable-tests
- make -f client.mk build
- Go get breakfast/lunch/dinner because it took over 2 hours on my machine.
Building Eudora (Thunderbird + Penelope + Eudora branding) on OS X
The steps to build Eudora from CVS on OS X are almost identical to the instructions for Linux. There are may caveats depending on whether you want a universal binary, which version of OS X you have, which version you want to target, etc. More thunderbird OS X build details can be found at [developer.mozilla.org].
The only deviation from the Linux directions is the installation of LibIDL and GLib, and contents of the ~/.mozconfig file.
- Rememer to do the following:
chmod +x ./configure chmod +x ./build/autoconf/mozconfig*
- Install LibIDL (via orbit) and GLib using fink:
$ sudo apt-get update $ sudo apt-get install orbit orbit-dev glib
- Create ~/.mozconfig with:
export CC=gcc-3.3 export CXX=g++-3.3 . $topsrcdir/mail/config/mozconfig ac_add_options --enable-prebinding ac_add_options --disable-tests ac_add_options --enable-extensions=default,penelope ac_add_options --with-branding=other-licenses/branding/eudora
Reducing Build Time
The ThunderBird folks advise building in a subdirectory or subdirectories when making a change to the code to reduce the amount of time needed to build. By a narrowing down the build to at least the component you need to rebuild you can cut the compile time dramatically. You can cut down the build time even further by specifically providing the change logic yourself and rebuilding only those portions of the code that you know you changed.
If you use a separate object directory (as the default config suggests), then you'll need to look for the individual makefiles in the object directory hierarchy (for example in my setup I found them under "thunderbird-static" since that's my object directory name). Otherwise the makefiles will be alongside the source.
Scott MacGregor notes:
I don't use the objdir technique, but some developers really like it. Most of those folks like to use it because they are building multiple products like firefox and thunderbird and they only want to have one source tree directory. They can just point their thunderbird build at one objdir directory and the fx build at another, while working out of just one instance of the source tree. But I mostly just build thunderbird, so moving the objdir out of my source tree doesn't help me much.
Specific Example
A lot of the core Thunderbird functionality is provided in mail.dll, which is built from the mailnews directory.
For example, say I wanted to make a change to a portion of the IMAP code (e.g. I want to modify "nsIMAPNamespace.cpp").
Slow Method
The really slow method to recompile would be to invoke:
make -f client.mk build
in the root level of the mozilla source code. On my laptop, even with no changes to the source code, this takes over 12 minutes to complete.
Faster Method
A faster way to recompile would be to invoke "make" inside the mailnews directory (no arguments are needed for "make" since the mailnews directory contains "Makefile"). Without an object directory specified that would be mozilla/mailnews; with an object directory specified that would be something like mozilla/objectdir/mailnews.
On my laptop, this took less than 2 minutes to recompile.
Fastest Method
The fastest way to recompile would be to first invoke "make" inside the mailnews/imap directory.
Then invoke "make" inside the mailnews/build directory (which just re-links mail.dll).
On my laptop, this took less than 10 seconds to recompile (ignoring time for me to type, change directories, invoke the 2nd command etc.)
Troubleshooting
Here are some problems that have cropped up during development:
- The prefs.js file in the profile directory may have stale settings in it which override the behavior you are trying to test. You must remove them manually.
- On Linux the profile directory is in ~/.thunderbird/
- On Mac OSX the profile directory is in ~/Library/Thunderbird/Profiles/
- On windows the profile directory is C:\Documents and Settings\<Windows login/user name>\Application Data\Thunderbird\Profiles\
- The extensions subdirectory may contain the penelope extension if it was installed for Thunderbird. This will conflict with an install of Eudora because the penelope extension resides in the Eudora install directory. Both extensions will be applied at the same time which will cause problems. If you install Eudora, you must remove any previous install from the profile directory
- Beware cross-volume symlinks (see Discussion page)
- Very bad things happen when you have an unresolved entity (missing a DTD file or entry in a DTD file). This can manifest as the whole application is a window with zero size (which is very hard to find!).
- Multiple key mappings occur when they are scoped in different keysets. When redefining a key mapping, make sure it is done in the correct keyset ID.
- Some key mappings canot be set via the prefs file. They seem to be dynamically updated via a xul overlay at run time. The only way I have found to redefine these keys is to create an overlay that remaps the keys.
- If the resulting build in dist/bin will not run try adding execute permission to dist/bin/run-mozilla.sh
- Some developers have had problems when the root source directory was not named "mozilla" (e.g. not being able to use MOZ_OBJDIR to put generated files in to a separate directory from the source). This is unfortunate because our trunk in Perforce is named "eudora", which means you need to set up a client-spec view to rename the directory locally. Also bad because there already is a directory named "mozilla" at that same level, which contains the original code from Mozilla.org.
- To re-create the Makefiles you have to remove the generated configure files then re-run make:
rm config.log config.cache config.status mozilla-config.h make -f client.mk build