- Which systems are supported Mozilla build platforms?
- There are multiple levels or tiers of Mozilla build "support".
Tier-1 platform refers to platforms that are the primary focus for development. Major problems on these platforms are considered showstoppers. These are also the platforms that show up on the SeaMonkey tinderbox page. The tier-1 platforms are:
- linux/x86 (gcc)
- win32/x86 (msvc)
- OS X (gcc)
Tier-2 platforms are platforms for which a small varying subset of developers & contributors actively try to maintain but general development does not halt for problems on these platforms. These platforms are usually referred as the Ports as most of them reside on the SeaMonkey-Ports tinderbox page. The tier-2 platforms are:
- aix 4.3 (aCC)
- beos 5.0.3 (gcc)
- bsdi 4.x (gcc)
- hpux 10.x,11.x (HP cc)
- irix 6.x/gcc (gcc/MIPSpro)
- linux/ppc (gcc)
- os/2 (gcc)
- osf1 5.x (Compaq cc)
- solaris (sparc & x86) 2.6+ (gcc/Forte)
Tier-3 platforms are those platforms which generally are not actively worked on by the main developers of the project but have fixes contributed by third parties. Tier 3 platforms are:
- freebsd (gcc)
- linux/alpha (gcc)
- netbsd (gcc)
- openvms (?)
- ps2linux (gcc)
- qnx 6 (gcc)
- win32/x86 (gcc)
All other platforms are "unsupported" by the primary mozilla developers, where "unsupported" really means "not a priority and no one is actively working on it".
Most Mozilla developers do not have access to non-tier-1 platforms so any bugs reports against non-tier-1 platforms should be overflowing with information to help the owner of the bug determine the cause of the problem and the proper solution. If you can provide a patch and/or verify that the developer's patches work for your platform, that would help a lot towards getting your bugs fixed and checked into the tree.
- What type of build system does Mozilla use?
- Mozilla uses a thin GNU configure layer on top of a legacy Netscape recursive makefile build system on all platforms. Like most configure-based projects, it uses GNU autoconf to generate the configure script. GNU make is used to drive the build process.
- Why use GNU make?
- GNU make has been ported to a lot of systems. This makes porting Mozilla to those systems a bit easier. Using only the subset of make features that are supported by the native make program on 10 different platforms would make the build system unnecessarily complicated.
- Will any other version of make work?
- No. The Mozilla makefiles use GNU make specific features which will only work with gnu make.
- Why aren't you using automake?
- Part of Netscape's legacy system involved using GNU make's -include feature to include a common set of rules from a handful of files in every Makefile that needed to use them. With this centralized rule system, one of the primary selling points of automake was made inconsequential. Also, at the time, Mozilla's method of building libraries did not mesh well with libtool.
- What happened to the nmake and CodeWarrior build systems?
- They no longer exist in the current tree. nmake build support was dropped during the Mozilla 1.2a release cycle. The mac cfm build system was dropped along with OS9 support shortly after the Mozilla 1.3 release.
- Why not ant, tmake, scons or insert your favorite build system here?
- Mainly, because no one has implemented these systems for Mozilla. When Mozilla was first open sourced, it only contained the legacy Netscape system. The autoconf layer was added on a branch and maintained in parallel for 6 months before it became the standard build system for the unix build.
- If I wanted to implement my favorite build system for Mozilla, would Mozilla start using it? I don't want to waste my time if you aren't going to use it.
- There's no guarantee that any code written for Mozilla will be accepted into the default tree. Any build system that is implemented would have to show that it's better overall than the current build system. Speed, flexibility, portability and the ability for a large group of developers who have 3+ years experience with the current build system to easily transition to the new system would be the major factors in deciding to switch. If you are serious and willing to do lots of work, contact User:Benjamin Smedberg to discuss the details of your proposal.
- Why doesn't Mozilla support autoconf 2.5x?
- Simply put, autoconf 2.5x does not offer anything to make the upgrade worth the effort. Autoconf 2.5x is not backwards compatible with autoconf 2.13 and the additional restrictions made by the newer versions of autoconf would require a major rewrite of the Mozilla build system for questionable gain.
Some of the 2.13 features, such as the ability to pass additional arguments to sub-configures, are not available in 2.5x. People have asked repeated about those features on the autoconf mailing list without any favorable response. Rewriting the configures of the sub-projects of Mozilla (NSPR & LDAP) is not an acceptible tradeoff. The sub-projects are also standalone projects and forking an entire codebase because of a build system incompatiblity is silly.
- Why doesn't NSS use autoconf?
- The NSS project is also used outside of the Mozilla project and the NSS project members did not feel that moving to autoconf was worth the cost. See bug 52990 for details.
- Can I build multiple Mozilla-based projects from a single source tree?
- Yes! Each project must be built in its own objdir.
- What is an objdir?
- An objdir build refers to the process of creating the output files in a different place than where the source lives. This is a standard feature of most configure-based projects. It allows you build for multiple configurations, including multiple platforms if you use a network filesystem, from a single source tree. It also avoid tainting your source tree so that you know that the files in your tree have not been modified by the build process.
If you run configure by hand, you can use the standard method of creating an empty directory any place on the disk, changing to that directory and running /path/to/mozilla/configure from there.
mkdir obj-debug cd obj-debug ../mozilla/configure
If you use client.mk to build, you can add the following to your mozconfig file:
- Can I cross-compile Mozilla?
- Yes, see the Cross-Complining Mozilla document for details. No, Canadian Cross-Compiling is not supported.
- Do parallel (make -j) builds work for Mozilla?
- How do I force the build system to pick up any of the changes made to my mozconfig file?
- Touch any of the configure scripts in the tree. There is no explicit dependency upon the mozconfig file as the file can reside anywhere via the MOZCONFIG environment variable.
- error: file '../../toolkit/locales/en-US/chrome/necko/contents.rdf' doesn't exist at ../../config/make-jars.pl line 418, <STDIN> line 9.
- You are trying to build Firefox without following the instructions on Configuring Build Options. In particular, your mozconfig file must source the Firefox default mozconfig file:
. $topsrcdir/browser/config/mozconfig # add your custom additional options here
- Does Mozilla build on UFS?
- No but it will run on UFS. The asdecode utitily uses resource-forks which do not work on UFS. See bug 157036 for details.
- Can I use CodeWarrior to compile the Mach-O build?
- No, support for the CodeWarrior command line compiler tools has not been added to the tree. See bug 119589 for details.
Win32 specific questions
- Is there a Microsoft Visual Studio project file to build Mozilla?
- No. You must use cygwin and GNU make.
- Can I run the build commands from cmd.exe?
- Yes. Make invokes the cygwin /bin/sh subshell to execute commands so it does not matter what shell is used to initially invoke make.
- Which version of cygwin's autoconf package do I need to use?
- Because of the incompatibilities between autoconf 2.1x and 2.5x, the cygwin maintainers wrote a wrapper script which will determine which version of autoconf your configure script needs and invoke that version of autoconf. You will need the autoconf(-wrapper) & autoconf-stable packages. See http://cygwin.com/ml/cygwin-announce/2001/msg00177.html for details.
Unix specific questions
- Galeon needs libgtksuperwin.so but I don't have that file in my Mozilla gtk2 builds. Where is it?
- Only the Mozilla gtk1 builds build libgtksuperwin.so. If you want to use galeon with a gtk2 build, you will need to use galeon2.
- Why does configure say that it needs libIDL >= 0.6.3 when I have libIDL 0.8.x installed?
- libIDL 0.8x can only be used when compiling against gtk2. Mozilla compiles against gtk1 by default. To use libIDL 0.8.x and gtk2, you must specify --enable-default-toolkit=gtk2 on the configure command line or in your mozconfig file. NOTE: This is an old issue which has been fixed for mozilla 1.8.