diff options
Diffstat (limited to 'files/pt-br/mozilla/developer_guide/mozilla_build_faq/index.html')
-rw-r--r-- | files/pt-br/mozilla/developer_guide/mozilla_build_faq/index.html | 185 |
1 files changed, 185 insertions, 0 deletions
diff --git a/files/pt-br/mozilla/developer_guide/mozilla_build_faq/index.html b/files/pt-br/mozilla/developer_guide/mozilla_build_faq/index.html new file mode 100644 index 0000000000..5083040403 --- /dev/null +++ b/files/pt-br/mozilla/developer_guide/mozilla_build_faq/index.html @@ -0,0 +1,185 @@ +--- +title: FAQ de Compilação da Mozilla +slug: Mozilla/Developer_guide/Mozilla_build_FAQ +translation_of: Mozilla/Developer_guide/Mozilla_build_FAQ +--- +<h2 id="Questões_Gerais">Questões Gerais</h2> + +<dl> + <dt id="platform"><span id="result_box" lang="pt"><span class="hps">Quais sistemas</span> <span class="hps">são suportados</span> <span class="hps">plataformas</span> <span class="alt-edited hps">de compilação</span> <span class="hps">Mozilla</span><span>?</span></span></dt> + <dd>Ver <a href="/en/Supported_build_configurations" title="en/Supported_build_configurations">Supported build configurations</a>.</dd> +</dl> + +<h2 id="Localizando_erros"><span class="short_text" id="result_box" lang="pt"><span class="hps">Localizando</span> <span class="hps">erros</span></span></h2> + +<dl> + <dt><span id="result_box" lang="pt"><span class="alt-edited hps">A Compilação</span> <span class="hps">falhou</span> <span class="hps">sem qualquer</span> <span class="hps">mensagem de erro,</span> <span class="hps">como eu posso</span> <span class="hps">encontrar o problema</span><span>?</span></span></dt> + <dd><span id="result_box" lang="pt"><span class="hps">No seu diretório</span> <span class="hps">obj</span><span>, vá para o</span> <span class="hps">diretório no qual</span> <span class="alt-edited hps">de compilação</span> <span class="hps">falhou</span> <span class="alt-edited hps">e o tipo</span></span> <code>make</code> (ou <code>gmake</code> se necessario). <span id="result_box" lang="pt"><span class="hps">Isso vai</span> <span class="hps">relançar a</span> <span class="alt-edited hps">compilação para</span> <span class="hps">este pedaço</span> <span class="alt-edited hps">de código específico</span><span>, exibindo</span> <span class="hps">mensagens de erro</span> <span class="hps">mais</span> <span class="hps">detalhadas.</span></span></dd> +</dl> + +<h2 id="Questões_específicas_do_Win32"><span class="short_text" id="result_box" lang="pt"><span class="hps">Questões específicas do</span> <span class="hps">Win32</span></span></h2> + +<div class="note"><strong>Nota:</strong> Veja <strong><a href="/En/Developer_Guide/Build_Instructions/Windows_Prerequisites" title="en/Windows_Build_Prerequisites">Windows Build Prerequisites</a> </strong><span class="short_text" id="result_box" lang="pt"><span class="hps">para obter informações adicionais</span><span>.</span></span></div> + +<dl> + <dt>configure: error: installation or configuration problem: C compiler cannot create executables.</dt> + <dd>Look at the <code>config.log</code> 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 <code>start-msvc*.bat</code> 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.</dd> + <dt>xpt_link.exe: cannot find msvcr80d.dll.</dt> + <dd>This occurs with option <code>--enable-optimize=-Od</code> to disable any optimizations. The xpt_link.exe tool is also created using this <code>-Od</code> option. To fix this, copy <code>obj-dir/xpcom/typelib/xpt/tools/xpt_link.exe.manifest</code> to <code>obj-dir/dist/bin</code>. 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 <code>-Od</code> is specified. To copy all manifest files to the <code>dist/bin</code> directory, issue: <code>find ./ -iname *.exe.manifest -print0 | xargs -0 -t -i cp {} dist/bin</code> from the <code>obj-dir</code></dd> + <dt>client.mk:121 *** This source tree appears to have Windows-style line endings.</dt> + <dd>This occurs when you are using git and do not have the proper line ending settings. The commands to set the proper line endings are: + <pre class="bz_comment_text" id="comment_text_12"><span class="quote">git config core.autocrlf false +git config core.eof lf +git ls-files -z | xargs -0 rm +git checkout .</span> +</pre> + </dd> +</dl> + +<h2 id="Mingw32-specific_questions">Mingw32-specific questions</h2> + +<ul> + <li>If the configure or build fails due to a missing w32api, add the mingw32's /include directory to the end of your INCLUDE environment variable. Mingw32 libraries or binaries should not be needed, only the headers.</li> +</ul> + +<h2 id="Unix-specific_questions">Unix-specific questions</h2> + +<dl> + <dt>How do I build on Solaris 10 x86?</dt> + <dd>See <a href="/En/Developer_Guide/Build_Instructions/Solaris_Prerequisites" title="en/Solaris_Build_Prerequisites">Solaris Build Prerequisites</a>.</dd> +</dl> + +<h2 id="Mac-specific_questions">Mac-specific questions</h2> + +<dl> + <dt> </dt> + <dt>It doesn't work</dt> + <dd>That's not a question :) For common Mac build errors and additional troubleshooting tips, see <a href="/En/Developer_Guide/Build_Instructions/Mac_OS_X_Prerequisites#Troubleshooting" title="en/Mac_OS_X_Build_Prerequisites#Troubleshooting">Troubleshooting</a> in <a href="/En/Developer_Guide/Build_Instructions/Mac_OS_X_Prerequisites" title="en/Mac_OS_X_Build_Prerequisites">Mac OS X Build Prerequisites</a>. In particular, <code>bootstrap.py</code> can diagnose and suggest fixes for most common errors (wrong Xcode version, missing build dependencies).</dd> +</dl> + +<pre class="bz_comment_text" id="comment_text_12">curl https://hg.mozilla.org/mozilla-central/raw-file/default/python/mozboot/bin/bootstrap.py > bootstrap.py && python bootstrap.py</pre> + +<dl> + <dt> </dt> + <dt>Can I build a Mozilla application as a Universal Binary?</dt> + <dd>Yes. See <a href="/en/Mac_OS_X_Universal_Binaries" title="en/Mac_OS_X_Universal_Binaries">Mac OS X Universal Binaries</a> for instructions.</dd> +</dl> + +<h2 id="Fazer_Compilar_mais_rápido"><span class="short_text" id="result_box" lang="pt"><span class="alt-edited hps">Fazer</span> <span class="alt-edited hps">Compilar</span> <span class="hps">mais rápido</span></span></h2> + +<p><a name="rebuild_from_objdir"> </a></p> + +<ul> + <li><a name="rebuild_from_objdir"><span id="result_box" lang="pt"><span class="hps">Em geral</span><span>, a mudança</span> <span class="hps">em sua</span> <span class="hps">objdir</span><span>, mude</span><span>-se</span> <span class="hps">para o diretório específico</span> <span class="hps">onde pretende</span> <span class="alt-edited hps">de compilação</span> <span class="atn hps">(</span><span>a estrutura de diretórios</span> <span class="hps">do</span> <span class="hps">objdir</span> <span class="hps">corresponde à estrutura</span> <span class="hps">dos</span> <span class="hps">diretórios</span> <span class="hps">de origem</span><span>)</span><span>,</span> <span class="alt-edited hps">e o tipo</span> <span class="hps">apenas </span></span>"make" (or "gmake" if necessary). This only works if you find a directory that contains a "Makefile" (the equivalent directory in the source tree will contain a "Makefile.in"). If you want to get even more specific than that, you can try "make <filename>.obj".</a></li> + <li><a name="rebuild_from_objdir">If you have changed code of Gecko, e.g. in content/, dom/ or layout/, you also need to build <code>make -C layout/build/</code></a></li> + <li><a name="rebuild_from_objdir">With libxul (all code in one library, which is the default for opt builds now), you need to also build <code>make -C toolkit/library/</code></a></li> + <li><a name="rebuild_from_objdir">On Mac, you will also have to build<code> make -C browser/app</code></a></li> +</ul> + +<p><a name="rebuild_from_objdir"> </a></p> + +<p>Simply 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.</p> + +<dl> + <dd><a name="rebuild_from_objdir">See also </a><a href="/en/Incremental_Build" title="en/Incremental_Build">Incremental Build</a>.</dd> + <dt> </dt> + <dt>Windows builds using make are slow, is there any way to speed them up?</dt> + <dd> + <p>Yes! You should be using <a href="/en/pymake" title="en/pymake">PyMake</a> instead. PyMake recurses in a single process reducing the number of shell invocations, which are <a class="external" href="http://benjamin.smedbergs.us/blog/2009-04-02/pymake-25-faster-than-msys-make/" title="http://benjamin.smedbergs.us/blog/2009-04-02/pymake-25-faster-than-msys-make/">particularly expensive on Windows</a>. PyMake also allows for parallel builds on Windows without deadlocks.</p> + </dd> + <dt>Do parallel (make -j) builds work for Mozilla?</dt> + <dd> + <p>Yes. See the <a class="external" href="http://www.gnu.org/software/make/manual/html_node/Parallel.html">GNU Make Parallel Execution</a> manual entry for optimal usage.</p> + On Windows you must use PyMake if doing parallel builds (see above - keep in mind this is done automatically if building with <code>mach</code>). + + <p>As of December 2012, running builds through <code>mach </code>or<code> client.mk</code> 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:</p> + + <pre>mk_add_options MOZ_MAKE_FLAGS=-j8 +</pre> + </dd> + <dt>I have less than 4GB RAM, is there any way I can speed up linking?</dt> + <dd> + <p>Yes, disabling debugging symbols can speed up linking considerably. Add the following to your .mozconfig:</p> + + <pre>ac_add_options --disable-debug-symbols +</pre> + </dd> + <dt>How can I turn on distcc to help compilation?</dt> + <dd> + <p>In your .mozconfig file, add:</p> + + <pre>mk_add_options MOZ_MAKE_FLAGS="CC='distcc gcc' CXX='distcc g++' -jN" +</pre> + + <p>See the notes for parallel builds.</p> + </dd> + <dt>Can I use ccache to speed up builds?</dt> + <dd> + <p>Yes. See the <a href="/en/ccache" title="en/ccache">ccache</a> page for more details. Use of ccache is highly encouraged to speed up builds.</p> + </dd> + <dt>Where else can I save cycles?</dt> + <dd>Redirecting stdout, rather than dumping it into a terminal, can save between 30 seconds and 5 minutes on a build. Displaying lots of text is slow!</dd> +</dl> + +<h2 id="Build_configurations">Build configurations</h2> + +<dl> + <dt>Can I build multiple Mozilla-based projects from a single source tree?</dt> + <dd>Yes! Each project must be built in its own objdir.</dd> + <dt>What is a .mozconfig file?</dt> + <dd>It tells which Mozilla application to build and contains configuration options. See <a href="/en/Configuring_Build_Options#Using_a_.mozconfig_Configuration_File" title="https://developer.mozilla.org/en/configuring_build_options#Using_a_.mozconfig_Configuration_File">Using a .mozconfig configuration file</a>.</dd> + <dt>What is an objdir?</dt> + <dd> + <p>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.</p> + + <p>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.</p> + + <pre class="eval">mkdir obj-debug +cd obj-debug +../mozilla/configure +</pre> + + <p>If you use client.mk to build, you can add the following to your mozconfig file:</p> + + <pre class="eval">mk_add_options MOZ_OBJDIR=/path/to/objdir +</pre> + </dd> + <dt>Can I cross-compile Mozilla?</dt> + <dd>Yes, see the <a class="external" href="http://www.mozilla.org/build/cross-compiling.html">Cross-Compiling Mozilla</a> document for details.</dd> + <dt>How do I force the build system to pick up any of the changes made to my mozconfig file?</dt> + <dd>Touch any of the configure scripts in the tree. There is no explicit dependency upon the mozconfig file as the file can reside anywhere via the MOZCONFIG environment variable.</dd> + <dt> </dt> +</dl> + +<h2 id="Implementation_questions">Implementation questions</h2> + +<dl> + <dt>What type of build system does Mozilla use?</dt> + <dd>Mozilla uses a thin GNU configure layer on top of a recursive makefile build system on all platforms. Like most configure-based projects, it uses GNU autoconf to generate the configure script. GNU make is used to drive the build process.</dd> + <dt>Why use GNU make?</dt> + <dd>GNU make has been ported to a lot of systems. This makes porting Mozilla to those systems a bit easier. Using only the subset of make features that are supported by the native make program on 10 different platforms would make the build system unnecessarily complicated.</dd> + <dt>Will any other version of make work?</dt> + <dd>No. The Mozilla makefiles use GNU make specific features which will only work with gnu make.</dd> + <dt>Why aren't you using automake?</dt> + <dd>Part of Netscape's legacy system involved using GNU make's -include feature to include a common set of rules from a handful of files in every Makefile that needed to use them. With this centralized rule system, one of the primary selling points of automake was made inconsequential. Also, at the time, Mozilla's method of building libraries did not mesh well with libtool.</dd> + <dt>What happened to the nmake and CodeWarrior build systems?</dt> + <dd>They no longer exist in the current tree. nmake build support was dropped during the Mozilla 1.2a release cycle. The Mac CFM build system was dropped along with OS 9 support shortly after the Mozilla 1.3 release.</dd> + <dt>Why not ant, tmake, scons or <em>insert your favorite build system here</em>?</dt> + <dd>Mainly, because no one has implemented these systems for Mozilla. When Mozilla was first open sourced, it only contained the legacy Netscape system. The autoconf layer was added on a branch and maintained in parallel for 6 months before it became the standard build system for the unix build. Several experimental ports to various systems have failed because of the size of the project. Because building Mozilla involves much more than just compiling, any port requires system investment in creating custom rules.</dd> + <dt>If I wanted to implement my favorite build system for Mozilla, would Mozilla start using it? I don't want to waste my time if you aren't going to use it.</dt> + <dd>There's no guarantee that any code written for Mozilla will be accepted into the default tree. Any build system that is implemented would have to show that it's better overall than the current build system. Speed, flexibility, portability and the ability for a large group of developers who have 3+ years experience with the current build system to easily transition to the new system would be the major factors in deciding to switch. If you are serious and willing to do lots of work, contact <a href="/User:Benjamin_Smedberg" title="User:Benjamin_Smedberg">User:Benjamin Smedberg</a> to discuss the details of your proposal.</dd> + <dt>Why doesn't Mozilla support autoconf 2.5x?</dt> + <dd> + <p>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.</p> + + <p>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.</p> + </dd> + <dt>Why doesn't NSS use autoconf?</dt> + <dd>The NSS project is also used outside of the Mozilla project and the NSS project members did not feel that moving to autoconf was worth the cost. See <a class="link-https" href="https://bugzilla.mozilla.org/show_bug.cgi?id=52990" title="https://bugzilla.mozilla.org/show_bug.cgi?id=52990">bug 52990</a> for details.</dd> +</dl> + +<h2 id="See_also">See also</h2> + +<ul> + <li><a href="/en/Debugging_Mozilla_on_Windows_FAQ" title="en/Debugging_Mozilla_on_Windows_FAQ">Debugging Mozilla on Windows FAQ</a>: Tips on how to debug Mozilla on Windows</li> +</ul> |