View source for How the Build Works

== Talk Details == 

* '''Date''': Sept 20, 2006
* '''Speaker''': J. Paul Reed, Mozilla Corporation
* '''License''': [http://creativecommons.org/licenses/by-sa/2.5/ CC-BY-SA]

== Media ==

* [http://ilearn.senecac.on.ca/mozillalectures/lecture2part1.html Part I - Main Talk] (streaming)
* [http://ilearn.senecac.on.ca/mozillalectures/lecture2part2.html Part II - Question/Answer] (streaming)
* [http://ilearn.senecac.on.ca/mozillalectures/lecture2part3.html Part II - Question/Answer more] (streaming)
* [http://ilearn.senecac.on.ca/mozillalectures/mozillalecture2.mp3 MP3] (91 MB)
* [http://people.mozilla.com/~preed/SenecaPres/slides Slides]

== Talk Outline ==

<table style="width: 100%;" class="standard-table" cellborder=1 border=1 cellpadding=2 cellspacing=0>
<tr><th>Time</th><th>Topic</th><th>Details</th><tr>

<tr><td>00:00:13</td><td>Introducing J. Paul Reed</td><td>Professor David Humphrey of Seneca College introduces J. Paul Reed, Build Engineer, Mozilla Corporation.</td></tr>

<tr><td>00:02:00</td><td>Lecture Agenda</td><td>
Overview of the history of the build system.</td></tr>

<tr><td>00:03:00</td><td>"You Have the Wrong Guy"</td><td>Paul that he releases the software and considers himself more of a release engineer. You should be contacting the real build engineers Benjamin Smedberg, Mark Mentovai, Chris Seawood, and Bryan Ryner.</td></tr>

<tr><td>00:03:47</td><td>Paul's Background</td><td>Paul sheds some light on his background with the Netscape Build team (1998), his work on VM's at VMWare as release engineer and how he came full circle back to the project as a Moco (Mozilla Corporation) employee.</td></tr>

<tr><td>00:04:11</td><td>History of the build system</td><td>Paul mentions how Netscape had a collection of make files. Supporting 20 Unix platforms, Win16 & Win32.  The process was very mystical and brittle.  Documentation on the process was very crude.</td></tr>

<tr><td>00:05:50</td><td>Code Rush Documentary</td><td>Paul mentions the PBS documentary on the challenges of having three outsiders build Mozilla on the 3 platforms (Windows, Unix and Macintosh).</td></tr>

<tr><td>00:06:58</td><td>Autotools</td><td>On the limited use of autoconf and lack of usage of automake and other utilities.  Paul also elaborates on the autoconf systems usage of .in files and how they drive/fit into the build process.</td></tr>

<tr><td>00:07:50</td><td>No Autoconf?</td><td>Paul explains Why don't we need autoconf to build Mozilla?  An old machine at Mozilla monitors code checked (specifically config.in which is the source config file) in an automatically do this.</td></tr>

<tr><td>00:08:46</td><td>Major Organs of the build system Explained.</td><td>Paul discusses Netscape Portable Runtime (NSPR), Netscape Security Service (NSS), C-LDAP SDK, JavaScript, Supporting Libraries and most importantly the actual Mozilla products (Firefox, Thunderbird, Sunbird etc.)  All the above are in top level citizens, you get them whether or not you want them when you check out the code.</td></tr>

<tr><td>00:10:24</td><td>client.mk - Useful targets</td><td>
* '''checkout''' - grabs checkout of the source code (done this way so they can version the different modules - a feature that cvs does not support.)
* '''build''' - builds the application
* '''configure''' - run automatically when build is run
* '''fast-update''' - checks Bonsai and does an update and retrieves only the parts you are working on (unlike cvs update).</td></tr>

<tr><td>00:13:07</td><td>.mozconfig</td><td>Paul explains the importance of the .mozconfig file in the build process, and mk_add_option vs ac_add_options.
Build Configurator is here to help (http://webtools.mozilla.org/build/config.cgi)</td></tr>

<tr><td>00:15:43</td><td>Interesting things about build configuration.</td><td>
The system does not guess.  If the compile fails it knows it could not find it.
If the compiler knows where to find it and build system does not its still OK.</td></tr>

<tr><td>00:19:00</td><td>10 Lines</td><td>The 10 most important lines in build process.  The entire process for browser, Thunderbird etc. is driven by these 10 lines</td></tr>

<tr><td>00:19:54</td><td>Explanation of the Tiers</td><td>Paul discusses the various tiers in the build system and their contents.</td></tr>

<tr><td>00:23:22</td><td>Two Pass Build System Explained.</td><td>Paul elaborates on the export and libs pass (and sometimes also a thrid pass called deps). The  Export pass copies all the .h files for all modules. The libs pass creates libraries that are needed for other modules. The Deps pass handles the automatic dependencies for files that you have edited etc.  He stressed that all of this is still driven by the rules.mk file.</td></tr>

<tr><td>00:25:00</td><td>Explanation of the rules.mk file.</td><td>Good news: You need not necessarily worry about it.  Just know what the definitions are if you need to use them.  Paul also explains that the reason the makefile so short it is driven by the rules.mk file.</td></tr>

<tr><td>00:28:09</td><td>More rules.mk variables</td><td>Paul explains you can provide the build system will the all the information in needs to create your files.  Chrome is stored in .jar files.  The build system can handle .jars on their own, there need not be any rules. EXTRA_PP_COMPONENTS similar to C pre-processor defines in C.</td></tr>

<tr><td>00:30:47</td><td>MDC</td><td>Paul mentions that MDC has some great documentation on build flags and other build documentation.</td></tr>

<tr><td>00:33:43</td><td>Local vs. Official Builds</td><td>Paul explains the difference between a local build and the official ones from Mozilla, i.e. -d build ID (datestring), post build packaging commencing - for official builds it uploads to ftp mirrors (unlike local builds which just allow you to run them), talk back reports sent back to Mozilla.</td></tr>

<tr><td>00:35:36</td><td>Interesting parts of the Mozilla Build system.</td><td>Paul explains how the build system "cruft" and why it seems "weird". He discusses the reasons behind this. Specifically the use of autoconf as a thin wrapper as well as the issues accompanying use of top level directories in CVS.</td></tr>

<tr><td>00:38:23</td><td>The system is not as self-contained as it should be.</td><td>Currently localization packaging updates and generation are part of Tinderbox right now but this is not where it should be.  The right place for them would be the build system.</td></tr>

<tr><td>00:39:22</td><td>Re-inventing the wheel</td><td>Paul discusses why Mozilla has taken a not-invented here attitude. In essence he explains why they have re-written things already in existence on most modern systems.</td></tr>

<tr><td>00:40:40</td><td>Cross Platform Development</td><td>Paul discusses the remarkable fact that the browser can run on all three platforms without limited use of #ifdef pre-processor statements.  He remarked on the use of the NSPR and its benefits. Other oddities discussed include why C++ exceptions,templates and the 33 other portability rules (http://www.mozilla.org/hacking/portable-cpp.html#portability_rules)</td></tr>

<tr><td>00:44:50</td><td>Futures of the Build system</td><td>Paul discusses where the build system may be headed: Scons, Componentized builds, Moving to SVN</td></tr>

<tr><td>00:48:18</td><td>Re-write the whole thing.</td><td>Benjamin Smedberg threatens to re-write large (if not the whole) build system as the build engineers are starting to agree it may be easier to do that then to add stuff to it.</td></tr>

<tr><td>00:48:38</td><td>Useful notes for new developers</td><td>-DDEBUG-username useful for checking specific stuff when you yourself are debugging (can be turned off when you are done debugging).  --No remote -p prevents your existing Firefox profile from being corrupted when you build a custom version.</td></tr>

<tr><td>00:50:16</td><td>Helpful Tools</td><td>Paul discussed the use of other tools developers use and which would be useful to new entrants to the Firefox community. For example, MDC, tinderbox, LXR, Planet etc.</td></tr>

<tr><td>00:51:06</td><td>Obtaining Help</td><td>Paul explains that #build is meant for official builds and to talk to build engineers. They like to keep a high signal to roise For general questions and inquiries use #developers or #Seneca. However, he stressed that it is important not to hesitate to ask for help.</td></tr>
</table>