make (ou gmake se necessario). Isso vai relançar a compilação para este pedaço de código específico, exibindo mensagens de erro mais detalhadas.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.--enable-optimize=-Od to disable any optimizations. The xpt_link.exe tool is also created using this -Od option. To fix this, copy obj-dir/xpcom/typelib/xpt/tools/xpt_link.exe.manifest to obj-dir/dist/bin. There is another manifest file there, for xpt_dump.exe. Copy that as well. This error will probably appear for any compiled tool that is used during the build process when -Od is specified. To copy all manifest files to the dist/bin directory, issue: find ./ -iname *.exe.manifest -print0 | xargs -0 -t -i cp {} dist/bin from the obj-dirgit config core.autocrlf false
git config core.eof lf
git ls-files -z | xargs -0 rm
git checkout .
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/appSimply set the integer value after -j to the max number of parellel processes to use. For optimal builds, this should be around the number of processor cores in your system.
Yes! You should be using PyMake instead. PyMake recurses in a single process reducing the number of shell invocations, which are particularly expensive on Windows. PyMake also allows for parallel builds on Windows without deadlocks.
Yes. See the GNU Make Parallel Execution manual entry for optimal usage.
On Windows you must use PyMake if doing parallel builds (see above - keep in mind this is done automatically if building withmach).
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
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
Simply put, 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 incompatiblity is silly.