Autoconf for Mozilla

As of 8/19/1998, autoconf support is in the main Mozilla CVS tree. If you are not interested in using cvs, grab the patches against the release tarball from below.

Building with CVS

The AUTOCONF_1_0 branch has been merged with the HEAD branch. If you wish to see what changes were made to accomodate autoconf, click here.

You do NOT need to set the old build's environment variables when using autoconf.
The process should look something like:

cvs -z3 co MozillaSource 
cd mozilla
autoconf
mkdir obj-`./build/autoconf/config.guess`
cd obj-`./build/autoconf/config.guess`
../configure
make

If you are using a fresh tree, don't worry about messages like:

cvs checkout: move away mozilla/base/macbuild/base.mcp; it is in the way

Building with the release tarball

You will need *both* the moz-autoconf tar and diff files.

Files:

Latest:

moz-autoconf tar 1998073000

moz-autoconf diffs 1988073000

Process:

You will need to grab the 19980728 tarball from Mozilla Downloads. Untar the mozilla-1990728.tar.gz file. Untar the moz-autoconf tar file in the same directory. Then apply the moz-autoconf patch from that same directory.

The entire process should look something like:

cd /usr/src
tar -xvBpzf ~/mozilla-19980728.tar.gz
tar -xvBpzf ~/moz-autoconf.tar.gz
patch -p0 -s -b --suffix=.ac < ~/moz-autoconf.diff
cd mozilla
mkdir obj-`./config.guess`
cd obj-`./config.guess`
../configure
make

Notes:

You will need autoconf 2.12 (which requires GNU m4) or higher to use autoconf with mozilla.

NOT

Misc files:

patch for pngconf.h

patch for qglobal.h Removes hardcoded DEBUG define.

QTFE-1998073000 with autoconf support

GNOMEFE-1998073000 with autoconf support

gnome-config script

Building in the srcdir is disallowed as it causes problems if you want to later build in a subdir for a different configuration. You should create a subdirectory, obj-`./config.guess`. This is where you should actually run the build. From this directory, run ../configure.

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. However, the NSPR module is used by other products and is treated as a separate entity with its own set of config files. 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.)

Options

The following mozilla options supported by configure:

--with-jpeg Use the system jpeg library if available (broken)

--with-png Use the system png library if available (broken)

--with-zlib Use the system zlib library if available (broken)

--enable-fe=FE1,FE2 Use the FE frontends and check dependencies

--enable-crypto Enable use of SSL for https (untested)

--enable-netcast Enable use of netcast (untested)

--enable-java Enable java support (untested)

--enable-oji Enable use of Open JVM Interface (untested)

--enable-debug Override CFLAGS & DEFINES with debug options

--enable-profile Enable mozilla profiling (Solaris only)

--enable-mailnews Enable mail & news features (broken)

--disable-editor Disable composer

--disable-asserts Disable error asserts during debugging

--disable-async-dns Disable separate dns thread

--enable-shack HTML-embeddable native widgets (experimental)

--disable-shared Disable building of internal shared libs

--disable-static Disable building of internal static libs (broken)

--enable-tests Enable test stubs

--enable-homedir=$val Set mozilla user dir to $val (broken)