Thunderbird:Build

<< Back to Thunderbird Home Page

Build

Mozilla Developer Center has the documentation required to build Thunderbird.

To build on Mac OS X 10.5 Leopard,

1. Get your build environment up and running.

2. Check out your code on CVS. Be sure to decide if you want a trunk build or a branch build.

The following command works for the mozconfig shown below: (time, a Unix app, will tell you how long the compile took.)

$ time make -f client.mk checkout MOZ_CO_PROJECT=mail,calendar

A sample .mozconfig for a dual-core MacBook Pro, which checks out Thunderbird (with Lightning enabled) and Sunbird code at the same time:

# Sample .mozconfig
mk_add_options MOZ_MAKE_FLAGS="-j3"
mk_add_options MOZ_OBJDIR=@TOPSRCDIR@/../objdir-@CONFIG_GUESS@
mk_add_options MOZ_BUILD_PROJECTS="mail calendar"
mk_add_options MOZ_CO_PROJECT="mail calendar"
# For debugging, enable if necessary
#mk_add_options MOZ_CO_MODULE="mozilla/tools/trace-malloc"
#ac_add_options --enable-trace-malloc
# To enable multi-app compilation from one .mozconfig
ac_add_app_options mail --enable-application=mail
ac_add_app_options calendar --enable-application=calendar
# Compilation options
ac_add_options --disable-optimize
ac_add_options --enable-debug
ac_add_options --disable-static
ac_add_options --enable-shared
ac_add_options --with-macos-sdk=/Developer/SDKs/MacOSX10.4u.sdk
# Build Thunderbird with preinstalled Lightning if needed.
ac_add_options --enable-extensions=default,lightning

3. Compile the build: (feel free to replace "mail" with "calendar")

time make -f client.mk build MOZ_CURRENT_PROJECT=mail

4. To run the builds in Terminal in the following recommended way, go through the following commands:

• Set up for leak detection.

$ export XPCOM_MEM_LEAK_LOG=2

• mail-dumped.txt will show the objects dumped when shut down.

$ export XPC_SHUTDOWN_HEAP_DUMP=mail-dumped.txt

• Change into the directory where ThunderbirdDebug.app is found.

$ cd @@@YOURDIRECTORY@@@/objdir-i386-apple-darwin9.2.0/mail/dist/ThunderbirdDebug.app/Contents/MacOS/

• Create your profile here.

$ ./thunderbird-bin -Profilemanager --no-remote

• Run Thunderbird within gdb to get stack traces when the application crashes.

$ gdb ./thunderbird-bin

• Within gdb, type this command:

(gdb) handle SIG33 noprint nostop

• Run the debug Thunderbird build with your just-created profile.

(gdb) run -P "@@@YOURPROFILE@@@" -no-remote

• When the application crashes, run backtrace within gdb:
  • and attach the trace shown in your Terminal window as an attachment in a Bugzilla report if there are no other duplicates.

(gdb) backtrace

• To quit gdb, type:

(gdb) quit

Build Machines

This section outlines the proposed (minimum) build machines necessary for the MoMo infrastructure. The goal is to get a base infrastructure in place.

• Buildbot master. This will provide a web interface to see the status of any of the buildbot slaves. In addition, it should be possible to launch a build from this web interface as well.

• 3 Buildbot slaves, one for each platform. There are reference platforms available from MoCo. TODO: need link to the most current reference platforms. The linux and windows machines can be VMs. So far in MoCo, the mac build slaves are physical mac machines and not VMs. These would be responsible for the nightly and release builds.

• 3 Tinderbox clients. These will reside on the same VM and physical hardware as the Buildbot slaves, above.

• A Tinderbox server. We can most likely just use the existing Tinderbox server at MoCo. The tinderbox server simply receives emails about builds and updates a tinderbox waterfall.

It would be a good idea to build this as a staging environment and then when everything is running smoothly, build an identical environment for production. This does double the number of machines & VMs that we need to maintain, but it does give us a test / staging area to try out new configurations, software and extensions (such as integrating Talos test machines) to our build infrastructure.

At a minimum for our new staging environment, we would be looking at 1 MAC + 3 VMs (2 linux, 1 Windows). For a production environment, we would duplicate this.

To think about

• We may need 3 additional buildbot slaves in order to separate dep from the nightly & release builds. Otherwise, during a release we are in the position of not being able to do dep builds. This will become increasingly important as MoMo begins working on multiple lines of development.
• Apple does have some server virtualization stuff available. It may be worth investigating so that we can do all builds on VMs.
• Performance testing should not be done on VMs as results will most likely not be consistent. Perf tests should be done on dedicated hardware.

Helping With Build

TBD