Autoconf for Mozilla

Autoconf has become the primary build system for Mozilla. This means, among other things, that official and user-friendly build pages have sprung up. The classic build instructions are still available.

Leftover todo items

There are still a couple of build issues that need to be cleaned up.

Replacing the 3 pass system
Currently, everytime you do a 'make', it actually does a 'make export libs install'. This should be consolidated into a single pass.
There are two relatively difficult ways of doing this:
- Determine the intermodule dependencies and change the order of the directories so that modules only gets built after the modules it depends upon do. This is currently impossible due to the circular dependencies between some modules.
- Allow modules to directly reference other modules in INCLUDES rather than export the public headers into the $DIST/include directory. This has the potential side effect of modules using other modules private headers rather than public ones.
Add a proper install target
Currently, 'make install' just builds any targets in PROGRAM and installs them in $DIST/bin . Eventually, it'd be nice if 'make install' actually installed the relevant bins, headers and libs into the place designated by $prefix (set by configure).

Build Maintenance

For those interested in maintaining autoconf related files, I suggest you first familiarize yourself with the configure system. And reading the info pages wouldn't hurt either.

Transitioning from the old build system is fairly straightforward. The most obvious change you will see is that the old system placed the object files in platform specific directories in the source tree while autoconf places the object files into a platform specific object tree that mimics the source tree. Under the old system, there is the $DEPTH variable which specifies how far into the tree from the top you are. Since autoconf uses separate object trees, $DEPTH's meaning could change depending upon whether you needed a derived file (anything not contained in CVS) or a specific source file. Because of this, there are 2 standard autoconf variables that are used along with $DEPTH to determine which file is being referenced.

$topsrcdir refers to the location that the configure script actually resides (in this case, mozilla/).

$srcdir refers to the source directory that corresponds to the object directory the Makefile is in.

$DEPTH is only used to reference files relative to the top of the object tree.

Any files at are explicitly referenced with a relative path should $(srcdir) prepended to them. The most obvious example of such files are the header files (which are currently installed into a separated directory). For long lists of files, I generally use:

EXPORTS := $(addprefix ($srcdir)/, $(EXPORTS))

The current build system relies heavily upon platform specific defines. The autoconf build relies primarily upon functionality specific defines. The platform specific config/*.mk files will eventually be modified to define -DHAVE_somefunc instead of -Dplatform (which should be done by the compiler anyway) for the non-autoconf cases. In each platform.mk, there should be an ifdef USE_AUTOCONF that overrides the hardcoded values with the appropriate autoconf variables (see Linux.mk).

Currently, there is one configure script for the entire mozilla client. For a "proper" autoconf setup, one could argue there needs to be one per module so that each module can be completely independent. Since all of the modules are currently not completely independent, separate configure scripts would be overkill.

One goal of this project is to also move the platform specific knowledge to a central place. This allows others to become aware of the issues surrounding certain problems as well. (Like the problems with qsort under solaris which are only documented in xp_qsort.c.)