The Revival

Task list

Clean up the build system.


In particular, configure.in, config.mk and rules.mk could use a good cleansing. These three have cruft after cruft piled on top of them. For instance, there is no need for the ifdef USE_AUTOCONF s scattered throughout those files. Since autoconf is the default, the non-autoconf settings should be removed. If someone needs to look at them for "historical" reasons, then let them put bonsai to good use.

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.

Unfortunately, this has become near impossible to do now that we are using XPIDL generated headers. These headers are generated in a number of modules during the export pass.

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).

Removing custom scripts


The functionality in the detect_motif & detect_glibc scripts should be encapsulated in the aclocal.m4 file as m4 scripts that can be used natively by autoconf. JWZ improved the motif detection routines in xscreensaver so it may be possible to borrow the routines from there.

Support for win32


Currently, the win32 build system uses a separate set of makefile.win s to build Mozilla. This separation of build targets means that sooner or later a win32 developer is going to forget to update Makefile.in or a non-win32 developer will forget to update makefile.win.

It would seem as though the easiest way to accomplish this goal would be to make the windows build use confiure and GNU make. Unfortunately, it's not as simple was that. To use configure, we need /bin/sh, GNU autoconf, GNU m4 and GNU make for win32. The best known GNU tools for win32 are Cygnus' cygwin tools. These tools use a posix emulation layer to make porting standard unix programs a snap. However, this emulation layer slows things down tremendously. There is the mingw runtime which allows you to build native win32 apps that do not require the posix emulation layer. GNU make and bash built by mingw may allow us to avoid the speed penalty introduced by the posix emulation layer.

Cross compiling support


It is not always feasible nor practical to build Mozilla natively on a given platform. Modifying the build system to make mozilla cross-compilable would easily solve this problem.
So far, the framework for cross-compiling has been setup and NSPR has successfully been cross-compiled for i386-mingw32 from i386-linux.

Autoconf for NSPR


NSPR has traditionally used its own build system which is similar but separate from the classic build system.
Rationale that has been presented for not switching to autoconf previously was
• NSPR is used in other build systems so it should not be tied to Mozilla's build system and
  
• autoconf does not run under win32.
  
Making NSPR use autoconf will not make NSPR dependent upon Mozilla in any way. Autoconf does run under win32 but it requires unix tools like sh and m4. Another compelling reason to use autoconf for NSPR is that it is near impossible to cross-compile using the classic build system. Autoconf simplifies the cross-compiling process significantly.

This task is about 90% complete. All that remains is to move the logic from the various nsprpub/config/*.mk files into nsprpub/configure.in and add support for MSVC.

Tasks 1, 5, 6 and 7 are well under way. The work in progress can be found on the AUTOCONF_NSPR_WIN32_XCOMPILE_19990621_BRANCH branch.

Build Maintenance

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.

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