[N.B.: These notes may no longer reflect reality]
Seamonkey build/release
I. Build System
A. Developer
For mozilla, this info is up to date at http://www.mozilla.org/build/
For commercial, this info is http://warp/projects/client/seamonkey/
The process for each platform is basically the same:
* Configure your machine with the proper toolset
* Checkout a script or set of scripts
* Use the scripts to checkout the correct source and build the tree
1. Unix
Thanks to Steve Lamm and Chris Seawood, we have a great way to
configure unix builds: http://webtools.mozilla.org/build/config.cgi
Thanks to the efforts of Ramiro and Chris McAfee, the default options
are pretty sane.
a. mozilla
* cvs -d :pserver:user%netscape.com@cvs.mozilla.org:/cvsroot
co mozilla/client.mk
* cd mozilla; gmake -f client.mk
Note that if you have a built tree already, this will re-checkout
the source code and use automatically generated dependency
files to do a depend build.
Other useful targets are:
* clean, clobber_all: removes all files specified in the
$(TRASH) macros defined in the local makefiles.
* cleansrcdir: removes all object files and generated files
* checkout, pull_all: check out the source only.
* build: build only (assumes a checked out tree).
b. commercial
Building a commercial tree assumes that you've built a
mozilla tree in the directory you're going to check out
the ns tree.
* cvs -d :pserver:user@cvsserver:/m/src co ns/client.mk
* cd ns; gmake -f client.mk
2. Windows
a. mozilla
Basically, the same as unix, though not as flexible.
* cvs -d :pserver:user%netscape.com@cvs.mozilla.org:/cvsroot
co mozilla/client.mak
* cd mozilla
* nmake -f client.mak
b. commercial
* cvs -d :pserver:user@cvsserver:/m/src co ns/client.mak
* cd ns
* nmake -f client.mak pull_netscape_commercial build_all
Ironically, build_all only builds the commercial client, so you
still have to build mozilla by hand before starting the
commercial build..
3. Mac
a. mozilla
* cvs checkout mozilla/build/mac
* run PullNGlayout.pl to pull the source
* run BuildNGlayoutDebug.pl to build a debug tree
b. commercial
B. Release
Why is the release process different than the developer process?
There are a few reasons: developers don't generally care about
packaging, developers generally want debugging symbols in their
binaries, not all developers want to work on all component
integration.
So, the automation written for release builds does *basically* the
same thing that developer builds do, with the following differences:
* Release builds create .xpi files and installers
* Release builds incorporate other, pre-built components
(security, spellchecker, flash, jvm, etc.)
* Release builds strip debugging symbols from the binaries and
push them to the talkback server, and also generate an id
to associate talkback incidents to the correct debugging
symbols
1. Unix
For daily releases, we use some automation scripts that are
descended from legacy code written to satisfy 2.x-4.x releases.
We are working to clean this up so that it reflects the process
that developers use, rather than manually doing the steps
that client.mk does automatically and transparently.
The constantly improving, currently in use, scripts are:
ns/build/unix/verification/seamonkey-spawn
ns/build/unix/verification/seamonkey-build
seamonkey-spawn spawns builds on all the machines we do unix
builds on (currently only linux and solaris 2.7 for seamonkey).
seamonkey-build is the meat of the process and does all the build
and delivery, forgoing the use of client.mk in favor separately
configuring and building.
This single script does both the mozilla.org releases and the
internal commercial build deliveries.
There are some differences in configure options from the default:
--disable-tests to avoid unnecessary building of non-released stuff
--with-extensions=default,irc to get the all-important chat client
--without-jpeg --without-zlib --without-png, so we build our own,
rather than relying on an existing set of system libraries.
2. Windows
Luckily, we didn't have much in the way of legacy windows automation,
affording the opportunity to write something that fits the seamonkey
build process better.
cm/client/windows/build-verification.pl (in /m/src) runs the
windows releases to mozilla.org and the internal commercial.
3. Mac
We don't quite have the applescript someplace readily viewable,
but trust me, it's really good!
C. Mechanics, how to.
1. Add files to build
* cvs add the file to the correct repository
a. unix
* Add the new source file to the appropriate *SRCS macro
in Makefile.in (this is later used to generate Makefile).
b. windows
* For c and c++ files, add the new target object to
C_OBJS or CPP_OBJS macro as appropriate.
* For idl files, add the idl source file to the XPIDLSRCS macro.
c. mac
* for new source files, add the new file to the list of files
getting built in the CodeWarrior project file associated with
the module you're building; add it to both the optimized and
release versions of the product.
* for new header files and resources, add the new file to the
MANIFEST file for export.
* for new project files, create the project and add it to the
list of built projects in
mozilla/build/mac/NGLayoutBuildList.pm, or
ns/build/mac/CommercialBuildList.pm
2. Add files to installer packaging.
Once you get your code built, naturally you want to include it in
the shipped product. To do this, you have to make sure that your
binaries and resource files (xul, gif, jpeg, png, whatever) are
included somehow in
mozilla/xpinstall/packager/packages-mac
mozilla/xpinstall/packager/packages-unix
mozilla/xpinstall/packager/packages-win
or
ns/xpinstall/packager/packages-mac
ns/xpinstall/packager/packages-unix
ns/xpinstall/packager/packages-win
You can even test the installer creation process yourself once
you've done a build, and you're on windows, and you have zip.exe
in your path, just run:
mozilla/xpinstall/wizard/windows/builder/build.pl
and you'll end up with an installer in
mozilla/dist/win32_d.obj/install
II. Verification Process / Development Model
A. Verifications
Opportunity to
* look for regressions.
* close the tree and focus on blocking bugs, if any are found.
* verify that optimized builds still work.
* verify that the packaging manifests are still up-to-date enough.
B. Tinderbox/Bonsai
* Helps make sure code builds XP
* Gives an easy way to track checkins and associate them
with bloat/bustage
* Gives very visible place to post checkin rules.
C. Sheriffs
1. Why do we need a sheriff?
2. Why isn't there just one sheriff, like there used to be?
3. Sheriff's tools:
* Bonsai (open/close the tree to checkins)
* the hook: http://bonsai.mozilla.org/toplevel.cgi?treeid=SeaMonkey
or http://warp.mcom.com/webtools/bonsai/toplevel.cgi
* Tinderbox!
III. FAQs
A. CVS
1. lock files
a. for mozilla, page-leaf@mozilla.org, or file a bugzilla bug
against server operations (http://bugzilla.mozilla.org)
b. internally, x4444 or helpdesk request
2. branches
B. Tools
1. lxr
2. bonsai
3. tinderbox
4. IRC/AIM
C. Resources