Revision 330203 of Incremental Build

  • Revision slug: Incremental_Build
  • Revision title: Incremental Build
  • Revision id: 330203
  • Created:
  • Creator: mnoorenberghe
  • Is current revision? No
  • Comment fix {{BuildDocsTOC()}}

Revision Content

{{BuildDocsTOC()}}

Now that you have set up and built your source tree for the first time, you're ready to start your own development cycle.

The best way to proceed is to use an Objdir approach. For example, if you're enhancing Mozilla storage and have made changes to mozStorageConnection.cpp.

Assuming that your Objdir has already been built and you used separate shared libraries build options, you will find that the corresponding components folder (for Thunderbird in this example) contains these files that include compiled mozStorageConnection.cpp functions (note that "obj-i686-pc-cygwin" might be different in your case):

/c/mozilla/obj-i686-pc-cygwin/dist/bin/components:
...
storage.xpt
strgcmps.dll
...

To incrementally rebuild Mozilla Storage component to reflect your changes in mozStorageConnection.cpp, you need to run make in the corresponding Objdir subfolder:

cd /c/mozilla/obj-i686-pc-cygwin/storage
make

Note that there's a time stamp change on the components files after make completes:

/c/mozilla/obj-i686-pc-cygwin/dist/bin/components:
...
storage.xpt
strgcmps.dll
...

Now you should be able to run your updated Thunderbird:

/c/mozilla/obj-i686-pc-cygwin/dist/bin/thunderbird.exe

If you will be performing incremental builds, it is also recommended that you use ccache to speed up subsequent compilation times. See en/ccache for info on configuring ccache.

Two-stage build

Many components build in sections, with a master build subdirectory that links the component together. Usually this build subdirectory lives under the component's main directory, but not always. When modifying files in subfolders of uriloader you also need to make in /c/mozilla/docshell/build and when modifying files in subfolders of content, dom, editor or view you also need to make in /c/mozilla/layout/build (except when building versions prior to 1.9 where editor has its own build subdirectory). In case you have built with --enable-libxul, in addition to the above steps you need to make in <path-to-obj-dir>/toolkit/library so that the newly created component libraries are linked into libxul.

The smartmake script (introduced here) is a convenient way to generate the necessary make commands for an incremental build. It takes the modified directories as arguments and uses its knowledge of basic dependencies to determine the required build commands.

Using sourcedir builds

Note that sourcedir builds are suggested against, and support will be removed eventually.

When using a srcdir build you're typically editing in a subdirectory of the component's main directory. However you can leverage the two-stage build to your benefit. Simply run make in the current directory to compile the modified source files, then run make in the component's build directory or in the alternative build directory in the cases listed above to link the component. This is particularly convenient when your editor invokes make and processes any error output.

Build times

To give you a rough idea, here some build times on an “average Windows XP PC”:

  • full build: 2 hrs (make clean; make all; - from top of source tree)
  • full dependency build: 30 min (make deps; - from top of source tree)
  • local incremental build: 1 min (make; - from <objdir>/storage)

Revision Source

<p>{{BuildDocsTOC()}}</p>
<p>Now that you have <a href="/en/Build_and_Install" title="en/Build_and_Install">set up and built</a> your source tree for the first time, you're ready to start your own development cycle.</p>
<p>The best way to proceed is to use an <a href="/en/Configuring_Build_Options#Building_with_an_Objdir" title="en/Configuring_Build_Options#Building_with_an_Objdir">Objdir</a> approach. For example, if you're enhancing <a class="external" href="http://mxr.mozilla.org/mozilla/source/storage/">Mozilla storage</a> and have made changes to <code><a class="external" href="http://mxr.mozilla.org/mozilla/source/storage/src/mozStorageConnection.cpp">mozStorageConnection.cpp</a></code>.</p>
<p>Assuming that your Objdir has <a href="/en/Build_and_Install" title="en/Build_and_Install">already been built</a> and you used <a href="/en/Configuring_Build_Options#Statically_Linking_Components" title="en/Configuring_Build_Options#Statically_Linking_Components">separate shared libraries build options</a>, you will find that the corresponding <code>components</code> folder (for Thunderbird in this example) contains these files that include compiled <code>mozStorageConnection.cpp</code> functions (note that "<em>obj-i686-pc-cygwin</em>" might be different in your case):</p>
<pre class="eval">
/c/mozilla/obj-i686-pc-cygwin/dist/bin/components:
...
storage.xpt
strgcmps.dll
...
</pre>
<p>To incrementally rebuild Mozilla Storage component to reflect your changes in <code>mozStorageConnection.cpp</code>, you need to run <code>make</code> in the corresponding Objdir subfolder:</p>
<pre class="eval">
cd /c/mozilla/obj-i686-pc-cygwin/storage
make
</pre>
<p>Note that there's a time stamp change on the components files after <code>make</code> completes:</p>
<pre class="eval">
/c/mozilla/obj-i686-pc-cygwin/dist/bin/components:
...
storage.xpt
strgcmps.dll
...
</pre>
<p>Now you should be able to run your updated Thunderbird:</p>
<pre class="eval">
/c/mozilla/obj-i686-pc-cygwin/dist/bin/thunderbird.exe
</pre>
<p>If you will be performing incremental builds, it is also recommended that you use ccache to speed up subsequent compilation times. See <a href="/en/ccache" title="https://developer.mozilla.org/en/ccache">en/ccache</a> for info on configuring ccache.</p>
<h3 id="Two-stage_build" name="Two-stage_build">Two-stage build</h3>
<p>Many components build in sections, with a master build subdirectory that links the component together. Usually this build subdirectory lives under the component's main directory, but not always. When modifying files in subfolders of uriloader you also need to make in /c/mozilla/docshell/build and when modifying files in subfolders of content, dom, editor or view you also need to make in /c/mozilla/layout/build (except when building versions prior to 1.9 where editor has its own build subdirectory). In case you have built with --enable-libxul, in addition to the above steps you need to make in &lt;path-to-obj-dir&gt;/toolkit/library so that the newly created component libraries are linked into libxul.</p>
<p>The <code>smartmake</code> script (<a class="external" href="http://www.joshmatthews.net/blog/2011/05/build-smarter-not-harder/" title="http://www.joshmatthews.net/blog/2011/05/build-smarter-not-harder/">introduced here</a>) is a convenient way to generate the necessary <code>make</code> commands for an incremental build. It takes the modified directories as arguments and uses its knowledge of basic dependencies to determine the required build commands.</p>
<h4 id="Using_sourcedir_builds" name="Using_sourcedir_builds">Using sourcedir builds</h4>
<p>Note that sourcedir builds are suggested against, and support will be removed eventually.</p>
<p>When using a srcdir build you're typically editing in a subdirectory of the component's main directory. However you can leverage the two-stage build to your benefit. Simply run make in the current directory to compile the modified source files, then run make in the component's build directory or in the alternative build directory in the cases listed above to link the component. This is particularly convenient when your editor invokes make and processes any error output.</p>
<h3 id="Build_times" name="Build_times">Build times</h3>
<p>To give you a rough idea, here some build times on an “average Windows XP PC”:</p>
<ul>
  <li>full build: 2 hrs (<code>make clean; make all;</code> - from top of source tree)</li>
  <li>full dependency build: 30 min (<code>make deps;</code> - from top of source tree)</li>
  <li>local incremental build: 1 min (<code>make;</code> - from <code>&lt;objdir&gt;/storage</code>)</li>
</ul>
Revert to this revision