Firefox/Tegra/Build Notes

This is a work in progress; pieces of the Windows Mobile Build Instructions might also be relevant and/or informative. However, they are targeted towards building Fennec/XULRunner for Windows Mobile.

Initial Setup

• Follow the instructions in Windows Build Prerequisites, installing at a minimum:
  • the mozilla-build environment
  • Visual Studio 2008 (2005 ought to work, but this guide has been written with 2008 in mind), with Smart Device support

• To reduce pain, grab an updated Mercurial from http://mercurial.berkwood.com/ -- install it in C:\mozilla-build\hg (overwriting the hg install that's there).

• Install the Windows CE 5.00 Standard SDK. If you have a SDK provided by a Windows CE 6 device manufacturer, it ought to work as well; this has only been tested with the CE 5.00 SDK.

Downloading the Source

I tend to use 'c:\proj' as the root for most of my work; replace that path as appropriate for your usage. I would suggest a path without spaces, though.

Mozilla uses the Mercurial version control system. For more detailed information, see this page. For creating your own patches and/or maintaining local changes, I'd suggest using the Mercurial Queues extension.

In 'C:\mozilla-build', there will be a few batch files -- fire up start-msvc9.bat to obtain a console window with paths set up for building. All commands are assumed to be executed within such a window.

• First, create some directories:
  • mkdir /c/proj
  • cd /c/proj

• Then check out the current source tree; this will grab a copy of the source in a directory called mozilla-central in /c/proj:
  • hg clone http://hg.mozilla.org/mozilla-central

• To update to the latest source, from the mozilla-central directory:
  • hg pull
  • hg update

NOTE: the MSYS environment that drives the build uses Unix-style forward slashes for path separators. Drive letters are also treated as directories, so "C:\proj" becomes "/c/proj". Note that MSYS will automatically translate "/c/proj" into "C:\proj" from the command line; this sometimes causes problems when trying ot pass arguments that start with "/" to programs. To get around this, use "//" -- for example, "dumpbin //exports". Or, use the - form of arguments if supported.

Run autoconf to generate the configure scripts

You'll need to repeat this step if configure.in or js/src/configure.in change; it doesn't hurt to do it too often, so I usually do this whenever I update the source tree.

• From /c/proj/mozilla-central:
  • autoconf2.13
  • cd js/src; autoconf2.13

Set up a mozconfig

The mozilla build system uses a mozconfig file to avoid having to pass many options to configure on the command line. Here's a sample mozconfig that I use for building:

ac_add_options --enable-application=browser

# Either --enable-debug or --enable-optimize should be specified;
# --enable-debugger-info-mobules ensures that debugging symbols are available
# even with an optimized build.

#ac_add_options --enable-debug
ac_add_options --enable-optimize
ac_add_options --enable-debugger-info-modules

ac_add_options --enable-libxul

ac_add_options --enable-jemalloc
ac_add_options --enable-splashscreen
ac_add_options --enable-faststripe

# buggy for ARM at the moment
ac_add_options --disable-ogg

ac_add_options --enable-activex
ac_add_options --enable-activex-scripting

ac_add_options --disable-windows-mobile-components

# Note that you need to give both CFLAGS and CXXFLAGS
CFLAGS="-QRarch6 -QRfpe-"
CXXFLAGS="-QRarch6 -QRfpe-"

# No need to build the tests for now
ac_add_options --disable-tests

# Disable some things that aren't necessary right now;
# these might or might not actually work should they be needed.
ac_add_options --disable-javaxpcom
ac_add_options --disable-accessibility
ac_add_options --disable-printing
ac_add_options --disable-oji
ac_add_options --disable-vista-sdk-requirements
ac_add_options --disable-updater
ac_add_options --disable-installer
ac_add_options --enable-image-decoders="png gif jpeg"
ac_add_options --disable-dbm
 
CROSS_COMPILE=1
MIDL=/c/Program\ Files/Microsoft\ Visual\ Studio\ 9/VC/ce/bin/x86_arm/midl.exe

ac_add_options --target=arm-wince
ac_add_options --enable-win32-target=WINCE
ac_add_options --enable-default-toolkit=cairo-windows

ac_add_options --with-wince-sdk="c:/program files/windows ce tools/wce500/standardsdk_500"

Copy & paste the above into a file in /c/proj, I'll call mine "mc-firefox-wince-opt".

Start a Build

NOTE: See "Patches" at the end of this to see if there are any outstanding bugs/patches that you should apply that aren't in the upstream tree yet.

• First, create a directory to hold the build tree. From /c/proj:
  • mkdir firefox-wince-opt

• Enter that directory, and run configure (note: you must specify the absolute path to the configure script; a relative path should work, but doesn't currently):
  • cd firefox-wince-opt
  • MOZCONFIG=../mc-firefox-wince-opt /c/proj/mozilla-central/configure

• Fire off the build (the -s prevents a whole bunch of unnecessary spew from make)
  • make -s

• If all goes well, you should have a complete build/install dir in "dist/bin" inside your firefox-wince-opt dir.

Running the Build

Copy the entire bin directory to the device, and run firefox.exe.

Patches

This section should ideally be empty, but it might contain things that fix performance or otherwise do useful things that aren't quite ready for getting checked in.

There are some patches that enable the ActiveX build in embedding/browser/activex/src/plugin . This uses the ATL that comes with VC9, which seems to work.

• activex-flash.patch
• Due to some reason that I haven't tracked down yet, MozActiveX.res might fail to build in embedding/browser/activex/src/plugin. Build it manually -- at the start of the build is fine -- with the following (replace the .rc dir appropriately for your source location):

C:\proj\firefox-wince-opt\embedding\browser\activex\src\plugin>rc -I"C:\Program Files\Microsoft Visual Studio 9.0\VC\ce\atlmfc\include" -r -Fo MozActiveX.res c:/proj/mozilla-central/embedding/browser/activex/src/plugin/MozActiveX.rc

Outstanding Issues

These are bugs specifically affecting Windows CE; they should all have bug #'s associated with them:

• Need to fix toplevel windows on CE -- largely fixed, but we need to figure out what the right window styles really should be.