Firefox/Tegra/Build Notes: Difference between revisions
Line 127: | Line 127: | ||
* {{bug|479525}} -- Fix nanojit on CE, and reenable JIT for content | * {{bug|479525}} -- Fix nanojit on CE, and reenable JIT for content | ||
* {{bug|476903}} -- Fix ARM xptcinvoke type marshalling for integral types smaller than 32 bits | * {{bug|476903}} -- Fix ARM xptcinvoke type marshalling for integral types smaller than 32 bits | ||
* {{bug|480088}} -- Use a single cached chunk of memory for painting, instead of allocating each time | |||
There are some patches that enable the ActiveX build in embedding/browser/activex/src/plugin . For some reason, adding the ATL include causes the rest of the build to fail, so this should be done at the end. Need to figure out a way to add the ATL include just in the plugin dir... | There are some patches that enable the ActiveX build in embedding/browser/activex/src/plugin . For some reason, adding the ATL include causes the rest of the build to fail, so this should be done at the end. Need to figure out a way to add the ATL include just in the plugin dir... |
Revision as of 08:37, 25 February 2009
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:
- 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 # 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 ac_add_options --enable-activex ac_add_options --enable-activex-scripting ac_add_options --disable-spellcheck ac_add_options --disable-windows-mobile-components 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.
NOTE: there's a bug currently with component registration; in the bin directory, delete the file called ".autoreg" to speed up startup.
NOTE: having the remote display tool open during startup dramatically slows down the startup process (10x or so). I'm guessing this is due to the heavy IO that we do on startup to read in our large file getting interrupted by screen reads? Not quite sure, but you can watch the numbers from bug 478701 go up by 10x when ardisp is connected.
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.
- bug 468883 -- ARMv6 SIMD pixman optimizations ported to armasm
- bug 479104 -- Fix plugins on WinCE; convert plugin code to unicode
- bug 479105 -- don't compile libreg
- bug 479106 -- call SetForegroundWindow on CE as well as Mobile, to avoid window starting up minimized
- bug 479525 -- Fix nanojit on CE, and reenable JIT for content
- bug 476903 -- Fix ARM xptcinvoke type marshalling for integral types smaller than 32 bits
- bug 480088 -- Use a single cached chunk of memory for painting, instead of allocating each time
There are some patches that enable the ActiveX build in embedding/browser/activex/src/plugin . For some reason, adding the ATL include causes the rest of the build to fail, so this should be done at the end. Need to figure out a way to add the ATL include just in the plugin dir...
- activex-flash.patch -- hack to build activex plugin support for WINCE and to fake it to pretend to be Flash; see note about ATL below.
- the ATL shipped with the CE5 SDK is not compatible out of the box with VS9, due to a C++ language change. To build with the activex patch, wince5-atl.patch needs to be applied from C:\Program Files\Windows CE Tools\wce500\STANDARDSDK_500 (small patch, can be applied by hand). The ATL that's present with VS9 can't be used for reasons I don't understand yet.
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.