make (or gmake if necessary). This will relaunch the build for this specific piece of code, displaying more detailed error messages.config.log in the obj... directory. Try checking to make sure your PATH variable includes all the necessary directories. If you are using mozilla-build, then you need to start ming32 with one of the start-msvc*.bat files. If your build environment has changed, you may need to delete your config.cache file (in your mozilla or object directory) and then build again.git config core.autocrlf false
git config core.eof lf
git rm --cached -r .
git reset --hard
bootstrap.py can diagnose and suggest fixes for most common errors (wrong Xcode version, missing build dependencies).curl https://hg.mozilla.org/mozilla-central/raw-file/default/python/mozboot/bin/bootstrap.py > bootstrap.py && python bootstrap.py
make -C layout/build/make -C toolkit/library/ make -C browser/appYes. See the GNU Make Parallel Execution manual entry for optimal usage.
As of December 2012, running builds through mach or client.mk will result in the optimal values being passed to make automatically. If you would like to change the default values, add something like the following to your mozconfig file:
mk_add_options MOZ_MAKE_FLAGS=-j8
Set the integer value after -j to the max number of parallel processes to use. For optimal builds, this should be around the number of processor cores in your system.
(note: I have found that relying on automatic setting may not yield optimum results, in my case manually setting make -j resulted in a 50% decrease in build time. -j1 may keep it from blocking / becoming unresponsive.)
Yes, disabling debugging symbols can speed up linking considerably. Add the following to your .mozconfig:
ac_add_options --disable-debug-symbols
In your .mozconfig file, add:
mk_add_options MOZ_MAKE_FLAGS="CC='distcc gcc' CXX='distcc g++' -jN"
See the notes for parallel builds.
Yes. See the ccache page for more details. Use of ccache is highly encouraged to speed up builds.
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 to build for multiple configurations, including multiple platforms if you use a network filesystem, from a single source tree. It also avoids 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:
mk_add_options MOZ_OBJDIR=/path/to/objdir
In other words, 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 acceptable tradeoff. The sub-projects are also standalone projects and forking an entire codebase because of a build system incompatibility is silly.