Build System Requirements
The Mozilla build system is a complicated collection of scripts and tools that build, link, and package Mozilla. The current build system, based on GNU autoconf and GNU make, is difficult to understand and is not very flexible. This document is an attempt to outline the requirements for any future build system that might replace our current build system.
- The build system must work initially on our tier-1 platforms: Windows MSVC, MacOSX/gcc, Linux/gcc.
- This means that the build system must be capable of handling windows-style paths. This may be accomplished through wrapper scripts.
- The build system must be patchable so that port owners can fix the build on all our supported platforms and compilers, including Windows mingw, Solaris, AIX, and BSD.
- Installing the build system must be extremely simple.
- The build system must support cross-compiling from *nix hosts.
- The build must produce correct results. This includes calculating dependencies correctly, while requiring minimum manual dependency notations. The build tools should be used to calculate dependency information whenever possible.
- Incremental rebuilds must be fast, and developers should be able to choose to rebuild only certain directories.
Because Mozilla has complex configuration requirements, the build system must be capable of performing all the same configuration checks that the current configure script performs, including:
- Try to compile a program with a specified set of compile and linker flags.
- Try to compile and run a program with a specified set of compile and linker flags.
- Checking for headers and libraries
- Search the system for the existence of required and optional headers and libraries.
- Using pkgconfig to locate headers and libraries
- Use pkgconfig to get correct compile and link flags for a specified package.
- Custom tests
- e.g. Compiling a file to assembly and searching the resulting file for a particular pattern
Also, the Mozilla source code can build multiple products from the same source tree. The following are build settings that must be configurable by the user:
- Users must be able to configure where the intermediate directory is located. This includes configuring this to a different disk.
- The build system must not modify the source directory in any way (must be able to build from a readonly location)
- Build trees in different configurations must not affect eachother in any way.
- Build files should be easy to read and understand.
- Mozilla has many custom rulesets that must be easily added to the build system.
- Lists of files and build options must be distributed across the source tree with the relevant module (no single centralized project file)
It is impossible to rewrite the current Mozilla system to a new system. We are going to have to either migrate from one system to the other over time, or develop a migration tool that can convert mozilla-style Makefiles to a new format.
It is probably a good idea to first convert a semi-independent project. This is why I'd like to start with Tamarin and try to develop a python-based build system for it. If it works out, we can examine converting the Mozilla configuration system first, and then go through the tree converting modules individually.
The only two pre-made solutions which come close to meeting our needs are SCons or its fork, WAF. These have the advantage that you can include the entire python build system in our source tree; users will not need to build/install any tools other than python.
SCons has problems, including poor support for configuration and a poor C/C++ dependency tool.
WAF is architecturally interesting, but doesn't have builtin support for MSVC and the documentation is byzantine.