diff options
| author | Peter Bengtsson <mail@peterbe.com> | 2021-04-29 11:14:49 -0400 |
|---|---|---|
| committer | GitHub <noreply@github.com> | 2021-04-29 16:14:49 +0100 |
| commit | 50c10e22a2a094f9d46edd56eb64d12f7652246f (patch) | |
| tree | bd5e7be4288b36a314eb38039261fe973c91468c /files/ko/mozilla | |
| parent | 7ce9d46289c8931c157dd1f676d427bee517dca2 (diff) | |
| download | translated-content-50c10e22a2a094f9d46edd56eb64d12f7652246f.tar.gz translated-content-50c10e22a2a094f9d46edd56eb64d12f7652246f.tar.bz2 translated-content-50c10e22a2a094f9d46edd56eb64d12f7652246f.zip | |
Remove Mozilla/Developer_guide (#691)
Diffstat (limited to 'files/ko/mozilla')
6 files changed, 0 insertions, 1146 deletions
diff --git a/files/ko/mozilla/developer_guide/eclipse/eclipse_cdt/index.html b/files/ko/mozilla/developer_guide/eclipse/eclipse_cdt/index.html deleted file mode 100644 index 23deaf4ffc..0000000000 --- a/files/ko/mozilla/developer_guide/eclipse/eclipse_cdt/index.html +++ /dev/null @@ -1,443 +0,0 @@ ---- -title: Eclipse CDT -slug: Mozilla/Developer_guide/Eclipse/Eclipse_CDT -translation_of: Mozilla/Developer_guide/Eclipse/Eclipse_CDT ---- -<h2 id="Using_Eclipse_CDT_for_Mozilla_development" name="Using_Eclipse_CDT_for_Mozilla_development">Introduction</h2> - -<p> </p> - -<p>Eclipse CDT (C / C ++ Development Tools)는 고급 코드 지원 (상속 / 콜 그래프 탐색기, 정의로 이동, 리팩토링, 자동 완성, 구문 강조 표시 등)을 사용하여 C 및 C ++ 개발을위한 오픈 소스 IDE입니다.이클립스는 자바 오픈소스 IDE로 유명합니다. 하지만 자바뿐만 아니라 C/C++ 개발도구의 기능도 갖는데요, 이를 이클립스 CDT라고 합니다. 이번 포스팅에서는 윈도우즈 환경에 이클립스 CDT를 설치하는 내용을 다루어보고자 합니다.</p> - -<h2 id="System_requirements">System requirements</h2> - -<p>Eclipse will use a lot of memory to fully index the Mozilla source tree to provide code assistance features (easily <strong>4 GB of RAM</strong>, although this will drop to just over 1 GB if you restart after indexing is complete). Therefore, it is not recommended if your machine only has 4 GB of RAM.</p> - -<h2 id="Installing_Eclipse">Installing Eclipse</h2> - -<div class="note"> -<p>Regarding <a class="link-https" href="https://code.google.com/p/llvm4eclipsecdt/" title="https://code.google.com/p/llvm4eclipsecdt/">llvm4eclipsecdt</a>, do not install or select this toolchain for Mozilla development. This plugin is intended mainly for managed projects but we use an unmanaged project for Mozilla (since it has its own build system). Using this plugin will result in parts of the UI described below being hidden or disabled.</p> -</div> - -<p>Download <a class="external" href="http://www.eclipse.org/downloads/packages/eclipse-ide-cc-developers/oxygenr" title="http://www.eclipse.org/downloads/">Eclipse IDE for C/C++ Developers</a> from the Eclipse download page.</p> - -<h3 id="Increase_Eclipses_memory_limits!">Increase Eclipse's memory limits!</h3> - -<div class="warning"> -<p>Make sure you do this!</p> -</div> - -<p>Before you use Eclipse with the Mozilla source you must increase its memory limits. When Eclipse's indexer tries to process the Mozilla source, Eclipse will need considerably more memory than it allows itself out of the box. You should <a class="external" href="http://wiki.eclipse.org/FAQ_How_do_I_increase_the_heap_size_available_to_Eclipse%3F" title="http://wiki.eclipse.org/FAQ_How_do_I_increase_the_heap_size_available_to_Eclipse%3F">increase its memory limits using the <code>eclipse.ini</code></a> in your installation directory (or in Eclipse.app/Contents/Eclipse/ if you're on Mac). Set something like <code>-Xms1G -Xmx5G -XX:MaxPermSize=1G</code> (initial heap space of 1 GB, max heap space of 5 GB, max perm-gen space of 1 GB).</p> - -<p>If you fail to increase these limits, then you will likely find that Eclipse hangs when you try to index or work with the Mozilla source later on.</p> - -<h2 id="Express_setup">Express setup</h2> - -<p>For the Eclipse indexer to work well you must first build Mozilla, so that it includes headers from the objdir etc. These can be found and processed by Eclipse.</p> - -<div class="warning"> -<p><strong>Note:</strong> Your <a href="/en-US/docs/Mozilla/Developer_guide/Build_Instructions/Configuring_Build_Options#Building_with_an_Objdir">MOZ_OBJDIR</a> must be outside the Mozilla source directory.</p> -</div> - -<p>Once your build is complete then <code>mach</code> can generate a useful Eclipse project on your behalf. Either run:</p> - -<pre class="brush: bash"># Create eclipse project and open it: -./mach ide eclipse -</pre> - -<p>Or else:</p> - -<pre class="brush: bash"># Create eclipse project without opening it: -./mach build-backend -b CppEclipse</pre> - -<p>This should take less than a minute. In the case of the <code>build-backend</code> command, instructions on how to open the project will be displayed after the command completes.</p> - -<h2 id="Setup_time">Setup time</h2> - -<div class="note"> -<p>Some points in the rest of this document below are old and taken care of by the mach commands described above (although some of the project configuration is not done automatically yet). Some of it like the section on building the index and usage tips are still relevant, and other parts still may provide useful background information to understand it in more detail on how Eclipse works.</p> -</div> - -<p>You can expect it to take an hour or so to work through these instructions if you're doing so for the first time.</p> - -<p>(This assumes that you already have a copy of the Mozilla source, and that you have also <a href="/en-US/docs/Mozilla/Developer_guide/Build_Instructions/Simple_Firefox_build" title="Simple Firefox build">built the source</a> so that you have a pre-existing object directory. If that's not the case, then get your build going now so that it can be running while you continue with the instructions below. FAQ: {{ anch("Why_does_Eclipse_need_an_object_directory.3F","Wait, why does Eclipse need an object directory?") }})</p> - -<h2 id="Code_assistance">Code assistance</h2> - -<p>Out of the box, Eclipse can provide some code assistance for the Mozilla source, but it will be incomplete and often just plain broken. If you set up Eclipse as detailed below it will do a much, much better job.</p> - -<h3 id="Important_background">Important background</h3> - -<p>To help you make sense of the instructions that follow (and so that you can modify them to meet your own needs if necessary), this section provides some background on what IDEs need in order to provide advanced code assistance, and what Eclipse CDT needs in particular.</p> - -<p>To be able to provide really good code assistance for a project's source code, IDEs like Eclipse need to carry out a thorough <a class="link-https" href="https://en.wikipedia.org/wiki/Static_program_analysis" title="https://en.wikipedia.org/wiki/Static_program_analysis">static analysis</a> of the project's source files, to build up a picture of the code (what Eclipse is trying to do when it "indexes" the source.) Static analysis involves parsing the source files, so naturally it can only produce good results if it has a sensible set of preprocessor defines, include paths and pre-include files for each source file. Since Eclipse doesn't initially have any of this information, the code assistance that it's able to provide out of the box is pretty broken.<br> - <br> - For projects the size and complexity of Mozilla, it's impractical to manually configure Eclipse when there is a valid set of defines and includes paths for each of the different parts of the source code. Happily, Eclipse makes manual configuration unnecessary. Like some other IDEs, that are used with projects like Mozilla that have their own build system. Eclipse provides a tool that can collect the options that are passed to the compiler for each file that's compiled during an actual build. This process is sometimes called "build option discovery" or "compiler option discovery".</p> - -<p>The way that Eclipse CDT does build option discovery is to scan the console output from a real build looking for lines where a compiler was invoked. For each line that invoked a compiler, it tries to figure out which source file was being built and what its include paths were. <u>If relative paths are used to specify the source file or any of its include paths (common in Mozilla), and if you fail to take steps to make sure the build output specifies which directory the compiler is invoked from, this will not be possible.</u> <em>If</em> Eclipse can successfully identify which source file was being compiled, then it can associate with that file the <em>resolvable</em> include paths, preprocessor defines, and pre-include files that were passed to the compiler.</p> - -<p>Note the requirements that this method of build option discovery imposes on us. First, Eclipse needs build console output for a complete build, so that it can find compiler options for as many source files as possible. The build must be explicitly instructed to output information that allows the directory, where the compiler is being invoked from to be identified (i.e., 'make' must be instructed to output "Entering directory..."/"Leaving directory..." lines). Finally, the build must not be parallelized, since that would result in the interleaving of build output from different directories (breaking resolution of relative paths by interleaving the "Entering directory..."/"Leaving directory..." lines), and the build must not be silenced/quietened.</p> - -<div class="warning">Conversely, note this very carefully: if you configure Eclipse to invoke a build process that is parallelized, silenced, or that fails to identify the directory that the compiler is being run from, then it <strong><u>will</u></strong> mess up the compiler options that Eclipse associates with your files, and that in turn will <strong><u>significantly</u></strong> degrade the quality of the code assistance that Eclipse will provide after it next re-indexes the code.</div> - -<p>These requirements aren't a very good fit with the typical Mozilla developer's wish to minimize build times, implying parallelized, silenced builds.</p> - -<p>The consequences of the above observations are this:</p> - -<div class="warning"> -<ul> - <li>It is strongly recommended that you invoke your normal (re)builds from the command line, <strong>externally</strong> of Eclipse.</li> - <li>Below we will configure Eclipse's build step so that you use it only occasionally to manually trigger a special "build" (actually a fast script that fakes a build) purely for the purposes of setting/updating the compiler options that Eclipse associates with each source file.</li> -</ul> -</div> - -<p>(Not using Eclipse to invoke your real builds does lose you some minor benefits that Eclipse has to offer, but these are worth sacrificing for much improved code assistance. See the {{ anch("Building from Eclipse") }} section below if you're interested in what you lose. If you're interested in future improvements to Eclipse that would allow parallel builds to be run from inside Eclipse while still allowing it to obtain the compiler options, see the FAQ {{ anch("Isn%27t_there_a_better_method_of_build_option_discovery.3F","Isn't there a better method of build option discovery?") }} below.)</p> - -<h2 id="Initial_workspace_preferences">Initial workspace preferences</h2> - -<p>When you open Eclipse, it will ask you to "Select a workspace" (a directory where Eclipse will store files that it generates during indexing, and so on.) It's recommended that you have a separate workspace containing only a single project for each Mozilla source tree [{{ anch("How_can_I_delete_my_Eclipse_project_and_start_over.3F","rational") }}], and that you choose a directory outside the Mozilla source. Something like $HOME/eclipse-workspaces/mozilla-tree-1, for example. After selecting an appropriate directory, click OK, then close the "Welcome" tab when the main Eclipse window opens.</p> - -<div class="warning">Before you proceed any further, check that your changes to Eclipse's memory limits have taken effect and are present in <code>Eclipse/Help > About Eclipse > Installation Details > Configuration</code>.</div> - -<p>To avoid confusion in this and the following sections, note that "workspace preferences" and "project properties" are different things (we'll get to the details below).</p> - -<p>Whenever you create a new workspace for a Mozilla source tree, you should be sure to turn off the following two settings in the workspace preferences (<code>Window > Preferences</code>, or <code>Eclipse > Preferences</code>) before creating a project in that workspace:</p> - -<ul> - <li>in "General > Workspace", disable "Build automatically"</li> - <li>in "C/C++ > Indexer", disable "Automatically update the index"</li> -</ul> - -<p>Turning off automatic indexing prevents the CPU intensive indexer from running at various stages during the steps below before we're ready.</p> - -<p>Select "General > Content Types", expand "Text > C Source File > C++ Source File", click "Add" and add "*.mm". Eclipse CDT doesn't currently understand Objective-C files (although there is <a class="external" href="http://code.google.com/p/objectiveclipse/" title="http://code.google.com/p/objectiveclipse/">a project that promises to add Objective-C support</a>), so for now, this is the best we can do to give Eclipse a chance of expanding its understanding of the source into the Objective-C files.</p> - -<p>Select "General > Editors > Text Editors". If you want line numbers, tick "Show line numbers". If you want a column marker to mark the 80th column to help with formatting code to Mozilla's 80 character line limit, tick "Show print margin" and set the value to 80.</p> - -<p>Select "General > Workspace" and select "Refresh using native hooks or polling" and "Refresh on access" to prevent Eclipse giving you annoying "Resource is out of sync" messages when files change from under it due to Mercurial or other external activity.</p> - -<p>Select "C/C++ > Build > Console" and set "Limit console output (number of lines)" to something large, like "1000000".</p> - -<p>Eclipse CDT will try to format C/C++ code that you add as you type. However, its default formats are not a good match to <a href="/en-US/docs/Mozilla/Developer_Guide/Coding_Style" title="Mozilla Coding Style Guide">Mozilla's style rules</a>. Download this <a href="/@api/deki/files/6241/=eclipse-formatter-for-mozilla.xml" title="https://developer.mozilla.org/@api/deki/files/6241/=eclipse-formatter-for-mozilla.xml">first pass at an Eclipse formatter configuration for Mozilla C/C++ coding style</a>, and install it by opening the workspace preferences, selecting "C/C++ > Code Style > Formatter", and then using the "Import" button to import that file. The "Active profile" field should then automatically change to "Mozilla". Depending on the area of the code that you work on, you may need to tweak this configuration using the "Edit" button. (Note that the format settings under "General > Editors > Text Editors" have no effect in C/C++ views, since the C/C++ settings are more specific and override those settings. However, you may still want to tweak those settings if you'll be editing other file types in Eclipse.)</p> - -<p>Select "C/C++ > Editor" and set "Workspace default" to "Doxygen".</p> - -<p>Select "C/C++ > Editor > Content Assist" and set the Auto-Activation delay to 0 so that autocomplete suggestions don't seem to be laggy. (Sadly, there is no auto-activation option to activate autocomplete suggestion., so as soon as you type any alphabetical character that may begin with a symbol name like there is in other IDEs.)</p> - -<p>Select "C/C++ > Editor > Save Actions" and deselect "Ensure newline at the end of file".</p> - -<p>Select "C/C++ > Editor > Scalability" and set "Enable scalability mode when the number of lines in the file is more than:" to something larger, like 100000.</p> - -<p>Select "Run/Debug > Console" and deselect "Limit console output".</p> - -<p>If you want to increase the text size in the editor, select "General > Appearance > Colors and Fonts", select "Basic > Text Font", and edit the font size.</p> - -<h2 id="Creating_an_Eclipse_project">Creating an Eclipse project</h2> - -<p>To create an Eclipse project for your Mozilla source tree, select "File > New > Makefile Project with Existing Code". In the "Import Existing Code" window that opens, enter a meaningful Project Name that identifies your Mozilla source tree, set the code location to the root of your source tree, select an appropriate Toolchain (e.g., "MacOSX GCC"), and click Finish.</p> - -<p>The status bar at the bottom right of the window should now show that Eclipse is "Refreshing the workspace" (gathering a list of all the files in the source tree). Click on the little green button beside this message to open the "Progress" tab, and keep an eye on the "Refreshing workspace" item as you continue with the steps below. (If an "indexing" item starts after the "Refreshing the workspace" item has finished, click the little red box beside that item to cancel it, since we want to configure the project before the indexer runs.)</p> - -<h2 id="Initial_project_properties">Initial project properties</h2> - -<p>So that the indexer will run faster and give better results, and so that Eclipse doesn't give results for irrelevant files, you should add some resource filters to have Eclipse ignore certain non-source files and directories. Note, <em>you must <u>not</u> make Eclipse ignore your (main) object directory</em>. That object directory is needed to resolve include paths to the various headers that the build process generates/copies there.</p> - -<p>To create resource filters, open the project properties (different to the workspace preferences!) by selecting <code>Properties</code> from the context menu for the project (root item) in the Project Explorer tab on the left, or by selecting <code>Project > Properties</code> from the menubar. Select "Resource > Resource Filters" on the left of the window that opens, then use the Add button to add the following filters:</p> - -<ul> - <li>Add an "Exclude all" filter for folders with a <strong>Project Relative Path</strong> matching ".hg". (This directory doesn't show in the Project Explorer tab, but Eclipse still indexes it without this filter!)</li> - <li>If you have secondary object directories (object directories that are <strong><u>not</u></strong> your only/the primary object directory) for the source tree and those directories are <strong><u>inside</u></strong> the source tree (or if you might have such object directories in future), then add an "Exclude all", <strong>regular expression</strong> filter for folders with a <strong>Project Relative Path</strong> matching "obj(?!-debug(?:$|/)).+". This particular regular expression will exclude all directories beginning with the string "obj" <strong>except</strong> "obj-debug", so if "obj-debug" is not the name of your main object directory, then adjust the regular expression as necessary.</li> - <li>Add a <strong>recursive, regular expression</strong> "Exclude all" filter for files with <strong>Name</strong> matching "\.(?:rej|orig|o|pp|swp)$" to exclude .rej, .orig, .pp, .o, and .swp files.</li> - <li>Add "Exclude all" filters for any other non-source directories that you've added to your source tree (e.g., Xcode or MSVC project directories).</li> -</ul> - -<p>Click OK to close the filters window, wait for Eclipse to finish processing your resource filters, then make sure the filtered directories and files have disappeared from the Project Explorer tab on the left. Also, if your <strong><u>main</u></strong> object directory is in your source tree, and not somewhere outside it, make sure that it has <u><strong>not</strong></u> disappeared from the Project Explorer tab.</p> - -<p>Reopen the project properties window and select "C/C++ Build" from the left of the project properties window. Select the "Builder Settings" tab, untick "Use default build command", set the build command to "just-print-mozilla-build.py" or, if you're on Mac, to "bash -l -c 'just-print-mozilla-build.py'" (on Mac Eclipse doesn't seem to pick up the environment properly, so it's necessary to invoke just-print-mozilla-build.py indirectly through bash). (just-print-mozilla-build.py is a fast script that we'll download in the next section.) (append '--objdir /path/to/objdir' if your objdir lives outside your tree) Set the build directory to "${ProjDirPath}/path/of/your/objdir/relative/to/the/root/of/your/source". Select the "Behavior" tab, delete the word "all" from the "Build (incremental build)" field, and disable the Clean checkbox.</p> - -<div class="warning"> -<p>If you can't untick "Use default build command", you must change the current builder by clicking on "Tool Chain Editor" (in C/C++ Build) and choosing another builder (e.g., "Gnu Make Builder").</p> -</div> - -<p>If you will not be using Eclipse for debugging, select "C/C++ Build > Settings" on the left, select the "Binary Parsers" tab, and make sure that all the parsers are deselected. This prevents the (useless if not debugging) "Searching for binaries" action from constantly interrupting everything.</p> - -<p>If you will be using Eclipse for debugging, select "C/C++ General > Paths and Symbols" and select the "Output Location" tab. You should now add the folder containing your Firefox binary (note on Mac this is inside the .app - so "{your-obj-dir}/dist/NightlyDebug.app/Contents/MacOS/" - and since the UI will only allow you to select to the 'dist' folder, you'll need to type the end of the path in manually). How you add this depends on whether your object directory is inside or outside your source tree. If inside, use the "Add Folder" button; if outside, use the "Link Folder" button and tick the "Link to folder in the file system" checkbox. Once you've added this folder, delete the existing output folder that was set to the root of the project. Doing this prevents the "Searching for binaries" which Eclipse constantly starts from taking too long.</p> - -<p>Select "C/C++ General > Preprocessor include Paths, Macros, and so on." Select the Providers tab. Make sure that "CDT GCC Build Output Parser" <strong>is</strong> selected, and that "CDT Managed Build Settings Entries" is not selected. Highlight (select) "CDT GCC Build Output Parser", then in the "Language Settings Provider Options" that appear below, make sure that "Share setting entries between projects (global provider)" is not ticked.</p> - -<div class="warning"> -<p><strong>If the main object directory for your source tree is a Fennec build</strong>: In the "CDT GCC Build Output Parser", change the compiler command pattern to</p> - -<pre>(.*gcc)|(.*[gc]\+\+)|(clang)</pre> - -<p>(before this change it should have been "(gcc)|([gc]\+\+)|(clang)"). This pattern is what CDT uses to identify compiler commands when parsing the build output. By default, it recognizes commands of the form "gcc", "g++", "c++", and "clang". This is fine for a desktop build, where the commands are in fact "gcc" and "g++". For Fennec builds, however, most of the commands are something like "arm-linux-androideabi-g++", which will not be recognized by the default regex. The modified regex accepts any command that ends with "gcc" or "g++". <strong>This may also affect other non-desktop builds besides Fennec.</strong></p> -</div> - -<p class="warning"><strong>Especially important</strong> if the main object directory for your source tree is located somewhere <strong><u>outside</u></strong> your tree's top source directory: If this applies to you, then select the Entries tab, select "GNU C++", select "CDT User Settings Entries", and click "Add". Change "Project Path" to "Filesystem", then select the 'dist/include' directory that's in your main object directory and click OK. Repeat these steps, but this time for "GNU C" instead of "GNU C++". (See the {{ anch("Headers are only parsed once") }} section below to understand why this step is important for people who have their object directory outside their source tree.)</p> - -<h2 id="Getting_code_assistance_working">Getting code assistance working</h2> - -<p>You're now ready to get code assistance working. :-)</p> - -<h3 id="Build_option_discovery">Build option discovery</h3> - -<div class="note">This section requires that you have already <a href="/en-US/docs/Mozilla/Developer_guide/Build_Instructions/Simple_Firefox_build" title="https://developer.mozilla.org/En/Simple_Firefox_build">built your mozilla source tree</a> (so that you have an object directory for it), and it is strongly recommended that the object directory is up to date so that the just-print-mozilla-build.py script runs quickly.</div> - -<p>As explained in the {{ anch("Code assistance") }} section above, to provide good code assistance Eclipse CDT needs to collect build information for the source files by processing a build log from a full, clean build made using -j1 -w. Since such a non-parallel, full build would take a very long time, we're going to cheat and set Eclipse's "Build" action to run jwatt's just-print-mozilla-build.py script instead. This script will complete in about 30 seconds on a warm tree (files cached in RAM) if your object directory is up to date, although Eclipse will take several minutes to process the "build output" that it produces.</p> - -<p>Download <a class="link-https" href="https://hg.mozilla.org/users/jwatt_jwatt.org/eclipse-cdt-tools/raw-file/tip/just-print-mozilla-build.py" title="https://hg.mozilla.org/users/jwatt_jwatt.org/eclipse-cdt-tools/raw-file/tip/just-print-mozilla-build.py">just-print-mozilla-build.py</a> and change its permissions to make it executable ('chmod a+x just-print-mozilla-build.py').</p> - -<p class="note">If you don't put just-print-mozilla-build.py somewhere in your PATH, then go back to the {{ anch("Initial project properties") }} section where you set just-print-mozilla-build.py and specify its absolute path instead of just its name.</p> - -<p>Now invoke the script by clicking the Build button (the button with the hammer symbol) or by selecting "Project > Build Project" from the main menu. That done, select the "Console" tab at the bottom of the main Eclipse window and you should see the build console output flying by as Eclipse processes it. It should take about 5-10 minutes for Eclipse to finish processing the output.</p> - -<h3 id="Additional_discovery_for_C11_mode">Additional discovery for C++11 mode</h3> - -<p><a href="/en-US/docs/Using_CXX_in_Mozilla_code" title="/en-US/docs/Using_CXX_in_Mozilla_code">As of Mozilla 25</a>, Mozilla is built in C++11 mode. When GCC is invoked in C++11 mode, it defines pre-processor symbols that enable conditional compilation of C++11 code in its standard library. To correctly parse this code, Eclipse CDT needs to know about these symbols. Unfortunately, the build option discovery process outlined above does not pick up this information, so CDT needs to be told separately about C++11 mode. To do this, go to "Preferences -> C/C++ -> Build -> Settings -> [Discovery] tab -> CDT GCC Built-in Compiler Settings" and add the flag "-std=c++11" at the end of the field labeled "Command to get compiler specs".</p> - -<div class="note">In CDT 8.3 (unreleased as of August 2013), there will be a more user-friendly way to specify this (see <a href="http://wiki.eclipse.org/CDT/User/NewIn83#Toolchains" title="http://wiki.eclipse.org/CDT/User/NewIn83#Toolchains">http://wiki.eclipse.org/CDT/User/NewIn83#Toolchains</a>).</div> - -<h3 id="Building_the_index">Building the index</h3> - -<p>Once you see the end of the build output in the Console tab and the Build item has disappeared from the Progress tab, you can start indexing the source. If indexing started automatically (see the Progress tab), cancel it, since there seems to be a bug that makes it give bad results when it starts automatically at this stage. Right-click the project root in the Project Explorer tab and select "Index > Rebuild". You will now see "Indexing..." in the status bar at the bottom right and an Indexing item in the Progress tab. It will take 10 minutes or so on a decent developer machine for a full rebuild of the index.</p> - -<div class="warning">Once the indexer has finished (keep an eye on the Progress tab), sanity check that everything went as it should have by right-clicking the project in the Project Explorer tab and selecting "Index > Search For Unresolved Includes". If you get many more than 2000 unresolved includes (as of May 2012), then things have gone pretty wrong. You should be able to use the list of unresolved includes to help figure out what the problem is (see also the {{ anch("Parser errors") }} section for more troubleshooting tips).</div> - -<p>Assuming everything went as expected, you should now find that Eclipse's code assistance works a whole lot better. :-) To test out the code assistance, see the {{ anch("Code_assistance_2","Code assistance") }} subsection of the {{ anch("Usage tips") }} section below.</p> - -<p>To improve code assistance even more, see the {{ anch("Headers are only parsed once") }} subsection of the {{ anch("Known Issues") }} section.</p> - -<h3 id="Keeping_the_index_up-to-date">Keeping the index up-to-date</h3> - -<p>As the source changes from day-to-day, you'll want to update the index to keep the code assistance working well.</p> - -<p>Since the compiler options used to build the source change relatively infrequently, the "build" step above doesn't need to be rerun all that often. Rerun it (and then rebuild the index) once a week or so, or as necessary when you start to notice unusual code assistance issues that aren't fixed by rebuilding the index alone.</p> - -<p>Rebuilding the index itself is required much more frequently since the source changes more frequently. In principle, you can set the index to rebuild automatically by opening the workspace preferences, selecting "C/C++ > Indexer", and reenabling "Automatically update the index". However, you may find this too disruptive, since re-indexing will then happen very frequently and code assistance can be broken while the index is rebuilding. The alternative is to leave that option disabled and update the index manually as necessary. To update the index manually, use the context menu in the Project Explorer tab on the left side of the window. To rebuild for changes in an individual directory (for example, to take account of some changes that you yourself made) select "Index > Freshen All Files" on that directory. To rebuild the entire index (for example when you pull from mozilla-central) select "Index > Rebuild" on the project root.</p> - -<h2 id="Usage_tips">Usage tips</h2> - -<p>Below are some of the more useful user tips. (If you're thinking of adding tips, please first consider how widely useful they'll be before adding to this already lengthy page.) For further documentation see the official <a class="external" href="http://help.eclipse.org/indigo/index.jsp?topic=/org.eclipse.platform.doc.user/gettingStarted/intro/overview.htm" title="http://help.eclipse.org/indigo/index.jsp?topic=/org.eclipse.platform.doc.user/gettingStarted/intro/overview.htm">Eclipse user guide</a> and <a class="external" href="http://help.eclipse.org/indigo/index.jsp?topic=/org.eclipse.cdt.doc.user/getting_started/cdt_o_tutorial.htm" title="http://help.eclipse.org/indigo/index.jsp?topic=/org.eclipse.cdt.doc.user/getting_started/cdt_o_tutorial.htm">Eclipse CDT user guide</a>.</p> - -<h3 id="Keyboard_shortcuts">Keyboard shortcuts</h3> - -<p>Regarding key bindings (keyboard shortcuts), the bindings given below are the defaults. You can change the key bindings by opening the workspace preferences (Eclipse > Preferences, or Window > Preferences) and selecting "General > Keys". You can set the scheme to "Emacs" or "Microsoft Visual Studio" if that's your thing, or change individual key bindings. When changing individual key bindings, <u>note that bindings are context sensitive and that any changes you make may be ignored</u> if they conflict with existing bindings, or if they are overridden by a binding for a more specific context. For example, changing the Find Next command to cmd-G/ctrl-G is not sufficient. For that to work you also either need to find the existing bindings for that key combination (using the Bindings column to sort by key combination helps with this) and remove them, or else you need to make your binding very specific by setting the "When" field to "C/C++ Editor" instead of the more general "Editing Text".</p> - -<h3 id="Opening_files">Opening files</h3> - -<p>You can quickly open a file by name using Cmd-Shift-R/Ctrl-Shift-R. Although Eclipse doesn't do fuzzy matching when you type a file name, it does allow you to use wildcards.</p> - -<p>To quickly switch between a source file and its header file, use Ctrl-Tab.</p> - -<p>To quickly switch to a recently viewed document use Cmd-F6/Ctrl-F6. If you want to change this awkward key binding, the command you need to rebind is "Next Editor".</p> - -<p>To show a filterable list of open documents (similar to the way Emacs gives you a list of open buffers), use Cmd-E/Ctrl-E.</p> - -<p>If you click the yellow, double arrow button at the top of the Project Explorer tab on the left, it will keep the selected file in the Project Explorer tab in sync with the file that you're currently editing.</p> - -<h3 id="Organizing_views">Organizing views</h3> - -<p>Use Ctrl-M to toggle maximization of the current editor view (the editor must be focused first).</p> - -<p>To tab to another view, use Cmd-F7/Ctrl-F7. This is useful if you have maximized the editor using Ctrl-M and you want to quickly see your search results. For example, without un-maximizing the editor.</p> - -<p>To side-by-side edit the same file in two different tabs, select the tab of the file that you want to edit, then from the menu bar select "Window > New Editor". This will open another tab containing the same file. Now simply drag that tab to position it beside, above, or below the original. Changes you make in one editor will be immediately reflected in the other.</p> - -<p>Note that the Search, Call Hierarchy, and other tabs have a "Pin" button that allows you to open multiple tabs of these type. This is useful if you want to keep your existing search results open, for example, and have a new search open in a separate tab rather than overriding the contents of the existing Search tab.</p> - -<h3 id="Code_assistance_2">Code assistance</h3> - -<div class="warning">Note: indexing, by its very nature, is specific to a given compiler configuration. Be aware that when Eclipse gives results for any of the actions that follow, it will not include results for sections of the code that are ifdef'ed out by the configuration used to create your object directory. For example, if you are using a Mac and you search for callers of nsDisplayListBuilder::IsInTransform, the results will not include the caller in nsObjectFrame.cpp because that caller is wrapped in "#ifndef XP_MACOSX". Just something to keep in mind. ;-)</div> - -<p>To jump to the definition of a symbol (or the declaration of a symbol if already at the definition), hover over the symbol, hold down the Ctrl/Cmd key, move the mouse slightly to linkify the symbol, then click on it. (Having to move the mouse slightly is <a class="link-https" href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=26873" title="https://bugs.eclipse.org/bugs/show_bug.cgi?id=26873">Eclipse bug 26873</a>). Alternately, you can jump to the definition of the symbol under the cursor by pressing F3.</p> - -<p>To do a C++ symbol search select "Search > C/C++" from the menubar, or use Ctrl-H and select the "C/C++" Search tab.</p> - -<p>To quickly find the definition of an enum, class, method, etc. use Ctrl-shift-t/Cmd-shift-t.</p> - -<p>To get a list of autocomplete options in an editor tab, start typing the name of an identifier and then type Ctrl-Space. Unfortunately, the autocomplete list cannot (currently) be configured to appear automatically as soon as you start typing a character that might be the start of an identifier name.</p> - -<p>To see the callers of a method (and their callers, etc.), select the method and use the context menu to select "Open Call Hierarchy". Note that there are buttons to the right of the "Open Call Hierarchy" tab that open to switch between "Show Callers" and "Show Callees".</p> - -<p>To see the inheritance tree for a class, select its name in an editor window and select "Open Type Hierarchy" from the context menu. Note that you can switch between "Show the Type Hierarchy", "Show the Supertype Hierarchy", and "Show the Subtype Hierarchy" using the buttons to the right of the "Type Hierarchy" tab.</p> - -<p>To see the overrides of a virtual method, select that method's name in an editor window and select "Open Type Hierarchy" or, "Quick Type Hierarchy" from the context menu. The results for "Open Type Hierarchy" will show all classes in the class inheritance tree, and the classes that have methods that override the method will have a triangular red marker beside them. If you select one of these classes, then in the method pane to the right the method you searched for will be highlighted (you may need to scroll to it) - double click to see its definition. The results for "Quick Type Hierarchy" will only show those classes in the inheritance tree that override the method. Double click on a class to go straight to its override's definition.</p> - -<h2 id="Building_from_Eclipse">Building from Eclipse</h2> - -<div class="warning">In short, don't do this. Eclipse doesn't have good facilities for building incrementally in individual directories in the way that Mozilla developers generally require. More importantly, unless you're willing to screw up Eclipse's code assistance (in which case why bother using Eclipse) you're going to have to set Eclipse's "Build" step to do a very slow, non-parallel, full rebuild. (See the "Code assistance" section above for why.)</div> - -<p>Nevertheless, if you understand the above warning and you still want to configure Eclipse's "Build" button to invoke a real build, then read on.</p> - -<p>Basically, you want to do something similar to the steps in the {{ anch("Initial project properties") }} section above, but use "make -j1 -wB" (or just "make" if you don't care about keeping code assistance working) instead of using just-print-mozilla-build.py.</p> - -<p>If you want to invoke "make -f client.mk" from your source directory instead of invoking 'make' from your object directory, then in the "C/C++ Build" section of the project properties, set "Build command" to "make -f client.mk" and set "Build directory" to just "${ProjDirPath}" (this is the top of the source tree). Select the Behavior tab and remove the "all" from the "Build (Incremental build)" field. Select "C/C++ Build > Build Variables", and add a variable "MOZCONFIG", and set it to the path of your .mozconfig file relative to the top source directory. Set any other environment variables you want to set for the build, then close the project properties window.</p> - -<p>Now when you hit the Build button (the little hammer icon), you should see the source build in the Console tab at the bottom of the window.</p> - -<p>The benefit of building from inside Eclipse is that build errors will appear in the Problems tab at the bottom of the window, and from there you can double click on the build error and it will take you straight to the source file and line where the problem occurred. For this to work reliably though, you still need to build using slow -j1 -w builds, so that make outputs non-interleaved "Entering"/"Leaving" lines. It also used to be necessary to add the following two lines to your mozconfig to make the compiler output errors all on a single line, but that may not be needed anymore:</p> - -<pre>export CFLAGS="-fmessage-length=0" -export CPPFLAGS="-fmessage-length=0" -</pre> - -<h2 id="Debugging">Debugging</h2> - -<p class="eval">To create a debug configuration, open the project properties window, and select "Run/Debug Settings" on the left. Click "New", then select "C/C++ Application". In the window that opens enter the path to your firefox binary (something like {your-obj-dir}/dist/NightlyDebug.app/Contents/MacOS/firefox) and select "Disable auto build". Select the Arguments tab and enter any args you want to pass to firefox (such as "--no-remote -p my-testing-profile"). If you're on Linux, you may also need to set the "Working directory" to {your-obj-dir}/dist/bin, and then select the Environment tab and set LD_LIBRARY_PATH to ".:./plugins:." and LIBRARY_PATH to ".:./components:.". (Are these variables really necessary? If so, why? Isn't LIBRARY_PATH for compile time, not runtime, linking?)</p> - -<p>In the workspace preferences, you may want to go to "C/C++ > Debug > GDB" and deselect "Stop on startup at", so that Eclipse won't automatically break in main() when it launches Firefox for debugging.</p> - -<p>To debug, click the Debug button on the toolbar, or select "Run > Debug" from the menu bar.</p> - -<p>It's not obvious, but <a class="external" href="http://wiki.eclipse.org/CDT/User/FAQ#Since_the_debugger_is_gdb.2C_can_I_simply_access_the_gdb_command_line_interface_.28CLI.29.3F" title="http://wiki.eclipse.org/CDT/User/FAQ#Since_the_debugger_is_gdb.2C_can_I_simply_access_the_gdb_command_line_interface_.28CLI.29.3F">you can get a gdb prompt in the console</a> so that you can type gdb commands directly.</p> - -<p>After you've finished debugging, you can get back to the C/C++ perspective (i.e. window layout) via the menubar by selecting "Window > Open Perspective > C/C++".</p> - -<h3 id="Upgrading_GDB_on_Mac">Upgrading GDB on Mac</h3> - -<p>The ancient, barely maintained Apple fork of GDB that comes with Xcode on Mac is really horrible. If you use Mac, you may want to <a class="external" href="http://sourceware.org/gdb/wiki/BuildingOnDarwin" title="http://sourceware.org/gdb/wiki/BuildingOnDarwin">build the latest FSF version of GDB</a> and set Eclipse to use that GDB for debugging. One suggested configuration for building GDB is '--prefix="$HOME" --disable-debug --with-python=/usr' (create an optimized build with <a class="external" href="http://sourceware.org/gdb/wiki/PythonGdbTutorial" title="http://sourceware.org/gdb/wiki/PythonGdbTutorial">support for Python</a> (so that you can use python to much better control when you break etc.), and install it in $HOME/bin). That done, open the workspace preferences, select "C/C++ > Debug > GDB", and set "GDB Debugger" to the full path of your new gdb executable.</p> - -<h3 id="GDB_unexpectedly_detaching">GDB unexpectedly detaching</h3> - -<p>If GDB starts ignoring your breakpoints, or unexpectedly terminates or detaches from the Firefox process, this may be caused by out of date breakpoints (breakpoints that you set during a previous debug session, after which you've since rebuilt). Remove any such breakpoints and restart your debug session.</p> - -<h2 id="Known_Issues">Known Issues</h2> - -<p>There are various known limitations and bugs when it comes to using Eclipse with Mozilla. Eclipse is open source, of course so if anyone feels like doing a bit of Java hacking to fix these issues that'd be great. </p> - -<h3 id="Headers_are_only_parsed_once">Headers are only parsed once</h3> - -<p>For performance reasons, Eclipse only processes header files that have include guards once, using the compiler options for the first source file it encounters that includes that header (<a class="link-https" href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=380511" title="https://bugs.eclipse.org/bugs/show_bug.cgi?id=380511">Eclipse bug 380511</a>). This is responsible for most of the parse errors in the source files displayed in Eclipse. One problem with the "parse once" strategy is that the compiler options for the original source file may ifdef out sections of the header, that would not be ifdef'ed out - and in fact are required by - source files in other parts of the tree.</p> - -<p>For example, in content/svg/content/src/nsSVGEllipseElement.cpp Eclipse shows a parse error due to NS_DOM_INTERFACE_MAP_ENTRY_CLASSINFO not being defined. This define is in nsDOMClassInfoID.h, which is included via the following include chain:</p> - -<pre>content/svg/content/src/nsSVGEllipseElement.cpp - content/svg/content/src/nsSVGPathGeometryElement.h - content/svg/content/src/nsSVGGraphicElement.h - content/svg/content/src/nsSVGStylableElement.h - content/svg/content/src/nsSVGElement.h - content/base/src/nsGenericElement.h - obj-debug/dist/include/nsDOMClassInfoID.h -</pre> - -<p>In nsDOMClassInfoID.h the NS_DOM_INTERFACE_MAP_ENTRY_CLASSINFO define is behind an |ifdef _IMPL_NS_LAYOUT|. The properties for nsSVGEllipseElement.cpp show that this define was picked up by the build option discovery and set on nsSVGEllipseElement.cpp, but somehow it's not set for nsDOMClassInfoID.h. However, if you right click on nsDOMClassInfoID.h in the Project Explorer and select "Index > Create Parser Log File", the log shows "Context" is set to "accessible/src/base/AccEvent.cpp", not "content/svg/content/src/nsSVGEllipseElement.cpp", and if you check the properties for AccEvent.cpp, indeed it is not built with the _IMPL_NS_LAYOUT define.</p> - -<p>One way to mitigate this problem is to explicitly define defines on problem directories. For example, to solve the _IMPL_NS_LAYOUT issue described above, you would use the context menu for the 'layout' directory in the Project Explorer tab to open the directory's properties. You'd select "C/C++ General > Prepocessor Include Paths, Macros etc.", and select "GNU C++" and "CDT User Settings Entries". You'd then click "Add", select "Preprocessor Macro" from the drop-down, and set Name to _IMPL_NS_LAYOUT and leave Value blank. Finally, you'd click OK twice to return to the main Eclipse window, and then use the context menu for the 'layout' directory to re-index the 'layout' directory, and then to "Run C/C++ Code Analysis" on it to see if the problem is fixed.</p> - -<p>This "parse once" strategy can also cause "Unresolved inclusion" errors in headers if the first time Eclipse sees the header is while indexing a file for which it doesn't have any build output parser data. (Since it then has no explicit include paths to search.) When this happens it frequently causes knock-on errors for the files that include that header (directly or indirectly), since they too now have things missing. People who have their object directory <u>out</u>side their source directory need to take special note of this issue. When the object directory is <u>in</u>side the source directory (and not filtered out by a resource filter), then Eclipse's "Allow heuristic resolution of includes" option (enabled by default) will generally allow the included headers to be found when Eclipse processes source files, that don't have any build output parser data. However, when the object directory is <u>out</u>side the source directory, Eclipse doesn't know about it - or the headers it contains - unless the user takes extra steps to tell it. This is the reason that the instructions in the {{ anch("Initial project properties") }} section above instruct users that have their object directory outside their source directory to explicitly add {objdir}/dist/include to the project's "CDT User Setting Entries".</p> - -<p>Fixing <a class="link-https" href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=381601" title="https://bugs.eclipse.org/bugs/show_bug.cgi?id=381601">Eclipse bug 381601</a> would considerably reduce the impact of the "Unresolved inclusion" issue. (Update 2017-03-28: The option <a href="http://wiki.eclipse.org/CDT/User/NewIn83#Preferences_for_header_variants">Index all header variants</a> has been added in version 8.3.0, as explained in a <a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=381601#c17">comment</a> of the mentioned bug. This option allows to have multiple definitions for the same header file, which might fix this issue. Update 2017-11-04 by jwatt: Ticking the "Index all header variants" option caused Eclipse to blow through the 12 GB of RAM I'd given it while indexing before it ran out of memory and crashed.)</p> - -<h3 id="There_are_parser_errors">There are parser errors</h3> - -<p>It is expected that Eclipse will show parser errors even for a known-good copy of the Mozilla source. Parser errors/warnings are indicated by red/yellow markers on files in the Project Explorer tab, and in the gutter down the right-hand side of open source files. In the case of the latter you can click on the marker to jump to the problem line and then hover over the "bug" icon to get an explanation of what's wrong.</p> - -<p>The parser error indicators don't seem to show (reliably?) until you open a source file, then error markers will be added for that file. To force all markers to show for a directory in the Project Explorer tab, right-click that directory in the Project Explorer tab and select "Run C/C++ Code Analysis". As well as adding the markers, this will give you a list of the issues in the Problems tab at the bottom of the window where you can double-click to jump to the location of any given issue.</p> - -<p>Many of the parser errors are the result of the {{ anch("Headers are only parsed once") }} issue, while others are the result of Eclipse trying to do its best to process files that are not built under your configuration (e.g. files compiled only on other platforms) and that therefore have no build output parser data associated with them.</p> - -<p>If you are trying to dig into a particular parser errors to figure out what it's about, here are a few things you can try:</p> - -<ol> - <li>Select your project in the Project Explorer, then from the context menu select "Index > Search for Unresolved Includes".</li> - <li>For problematic source files, select the file in the Project Explorer and from the context menu select "Index > Create Parser Log File".</li> - <li>Select your project in the Project Explorer, then from the context menu select "Index > Rebuild". When the indexing is done, open the log using "Window > Show View > Other > General > Error Log" and check the summary and look for exceptions.</li> -</ol> - -<h3 id="Searching">Searching</h3> - -<p>Free text search is not backed by a database, so it is <em>extremely</em> slow. Furthermore, the results are not saved so if you immediately search for the exact same text again without any changes to the source files having occurred, Eclipse will do a slow search all over again.</p> - -<p>It is not easy to restrict searches to an arbitrary directory, which is pretty annoying given how slow free text search is. (You have to create a new working set containing that directory.)</p> - -<p>Search history in a project is not preserved across restarts.</p> - -<p>Duplicate searches in history - even consecutive ones - are not coalesced.</p> - -<h3 id="Duplicate_files">Duplicate files</h3> - -<p>Sometimes when searching for files or symbols you will be given the option between a file in the source tree, and a file of the same name under the object directory. (Some source and header files are copied to the object directory by the build process, so we end up with copies in both places.) This will happen if your object directory is inside the source directory. If you don't want to switch to using an object directory that's outside your source tree, then this is just one of those things that you'll have to live with. (If you do change the location of your object directory, then note the instructions that will then apply to you in the {{ anch("Initial project properties") }} section above!) Since the indexer needs to be able to resolve header files in the object directory in order to produce good results, we can't have Eclipse ignore the object directory. But then there's no way to tell Eclipse that any given file in the object directory is actually just a copy of a given file in the source directory and that it should always show the user the copy in the source directory while using the file in the object directory for indexing.</p> - -<h3 id="Building">Building</h3> - -<p>Eclipse's support for building only in certain directories is non-existent. It would be great if the Console tab gave you a shell prompt so that you could invoke commands to build directly from there.</p> - -<p>Failing that, it would be nice if Eclipse could at least pass information about what files have changed to the build process, which could then decide on a faster way to do the build (e.g., "just make in layout/"). I (roc) have actually written a small change to the CDT Make builder that lets you specify that as an option, in which case Eclipse sends the names of all changed files to your build tool. The build tool is a Perl script that figures out if a faster build is possible and if so, does it.</p> - -<h2 id="FAQ">FAQ</h2> - -<p>Here are some frequently asked questions.</p> - -<h3 id="Why_does_Eclipse_need_an_object_directory">Why does Eclipse need an object directory?</h3> - -<p>To provide good code assistance Eclipse needs you to have a build directory for two reasons.</p> - -<p>First, Eclipse needs to be able to collect a usable set of defines, include paths, and preinclude files for the source files in the tree, as explained in the {{ anch("Code assistance") }} section above.</p> - -<p>Second, Eclipse CDT's indexer needs an object directory because virtually all Mozilla source files include header files (directly or indirectly) that have been copied to or generated in the object directory. Without an object directory, the indexer would find that a lot of header files are missing when processing the source files, which would significantly degrade its ability to index the source and provide good code assistance.</p> - -<h3 id="How_can_I_open_Eclipse_for_multiple_trees_at_once">How can I open Eclipse for multiple trees at once?</h3> - -<p>To be able to open more than one workspace at a time, you currently need to launch a <em>separate</em> Eclipse process for each workspace.</p> - -<p>On Mac, create a script called something like open-my-workspace.py, give it the following contents, replacing the bold paths as appropriate, and make it executable (chmod a+x open-my-workspace.py):</p> - -<pre>#!/usr/bin/env python -import os, subprocess -eclipse_app_path = <strong>"path/to/Eclipse.app/Contents/MacOS/eclipse"</strong> -workspace_path = <strong>os.path.join(os.environ['HOME'], "HOME/relative/path/to/the/directory/of/the/workspace/you/want/to/open")</strong> -subprocess.Popen([eclipse_app_path, "-data", workspace_path]) -# <strong>Uncomment the following line to automatically close the Terminal window</strong> -# <strong>that opens if you run this script by double clicking it in Finder.</strong> -#subprocess.Popen(["osascript", "-e", 'tell application "Terminal"', "-e", "close front window", "-e", "end tell"]) -</pre> - -<p>TODO: add instructions for Linux and Windows.</p> - -<h3 id="Is_there_a_Mercurial_plugin_for_Eclipse">Is there a Mercurial plugin for Eclipse?</h3> - -<p>There is <a class="external" href="http://www.intland.com/products/mercurialeclipse/download" title="http://www.intland.com/products/mercurialeclipse/download">MercurialEclipse</a>, but probably most Mozilla developers will just prefer to use the command line. If you think we need our own documentation on MercurialEclipse, please consider adding a separate page for that tool since this page is already pretty long.</p> - -<h3 id="How_can_I_delete_my_Eclipse_project_and_start_over">How can I delete my Eclipse project and start over?</h3> - -<p>If you followed the recommendation above to create one workspace containing only one project for each Mozilla tree, then this is easy. (If you didn't, and you have projects for more than one source tree entangled in a workspace directory, well, you're on your own.) Simply delete the <code>.project</code> and <code>.cproject</code> files and the <code>.settings</code> directory (if it exists) from the root of your Mozilla tree, and then delete the workspace directory corresponding to your tree. That's it; you can now create a new Eclipse workspace and project for your tree from scratch.</p> - -<h3 id="Isnt_there_a_better_method_of_build_option_discovery">Isn't there a better method of build option discovery?</h3> - -<p>Yes, but Eclipse doesn't currently support it. Instead of processing build console output, Eclipse could use something like LD_PRELOAD to load its own little library into all the processes that are invoked as part of the build process. This library could then check whether the process is a compiler instance and, if so, use the processes' current working directory and the arguments that were passed to it to reliably obtain the information it needs for each source file that is compiled. This would eliminate the requirement for non-parallelized, non-silenced builds. You could also build from Eclipse and get the benefits that that brings.</p> - -<h3 id="How_can_I_run_a_more_recent_CDT_version">How can I run a more recent CDT version?</h3> - -<p>This can be useful if you need to get certain bug fixes, or to help with testing to make sure that new Eclipse bugs that affect its use with Mozilla don't get shipped. If you've downloaded an <a class="external" href="http://www.eclipse.org/downloads/index-developer.php" title="http://www.eclipse.org/downloads/index-developer.php">Eclipse Developer build</a> then you can use Eclipse's software update mechanism to update your developer snapshot to the latest nightly for that developer branch. To do that, carry out the following steps.</p> - -<p>From Eclipse's "Help" menu select "Install New Software...", then in the "Install" window that opens, click "Available Software Sites". In the window that opens, click "Add", and in the prompt set Name to something like "Nightly" and Location to something like "<a class="external" href="http://download.eclipse.org/tools/cdt/builds/juno/nightly" rel="freelink">http://download.eclipse.org/tools/cd...s/juno/nightly</a>" (change "juno" to the current developer branch). Click "OK", then "OK" again. Type "Nightly" into the "Work with" field and select the repository that you just added. (If it doesn't appear, close the window, reopen it from the Help menu, and try again.) A "CDT Main Features" option should now have been added in the area below. Tick this (<em>all</em> of its sub-options should then be ticked), click "Next" twice, accept the license agreement, and then click "Finish". Eclipse should now update itself and ask you to restart.</p> - -<p><strong>Troubleshooting:</strong> If you get an error when trying to update, try clicking "Available Software Sites" in the "Install" window, make sure "Juno" is still unticked, that "Nightly" is ticked, highlight "Nightly", click "Reload", "OK", and then try again.</p> - -<h2 id="Troubleshooting">Troubleshooting</h2> - -<p>Here is a list of problems people have encountered, and suggestions for solutions.</p> - -<h3 id="Problem_Occurred_Java_heap_space">Problem Occurred (Java heap space)</h3> - -<p>If Eclipse becomes glacially slow or hangs and then you get this error message, see the {{ anch("Increasing memory limits") }} section above. If you already carried out the instructions in that section, then double check that your changes to Eclipse's memory limits actually took effect and are present in <code>Eclipse/Help > About Eclipse > Installation Details > Configuration</code>. If they did, then maybe you need to increase the limits still further for your OS/JVM combination.</p> - -<h3 id="Resource_is_out_of_sync_with_the_file_system">Resource is out of sync with the file system</h3> - -<p>If you get the message "Resource is out of sync with the file system", then you didn't set the "Refresh" options above in the {{ anch("Initial workspace preferences") }} section. Either set those, or else refresh the project (or an individual directory/file) manually using the Refresh item from the context menu in the Project Explorer tab.</p> - -<h2 id="Old">Old</h2> - -<p>Everything that follows is old content that should maybe just be deleted now?</p> - -<h3 id="GDB_Timeouts">GDB Timeouts</h3> - -<p>I don't think this old comment from 2007/2008 is an issue anymore.</p> - -<p>Out of the box, you may/will get GDB connection timeouts. This is because Eclipse is trying to push every subfolder in GDB's environment. The easiest way to resolve this issue is to remove any source entry from the debug configuration (Run->Open Debug Dialog...) in the Source tab. Doing so will, unfortunately, remove the binding between the binaries and the source code. To keep this feature working, you need to add a "Path Mapping" by clicking "Add..." in the Source tab. Once a "Path Mapping" is created, select "Edit..." and add an entry with these values</p> - -<pre class="eval"> Compilation path: / - Local file system path: / -</pre> - -<p>This is the only known workaround to bind binaries to source files. It has been tested and works perfectly under Eclipse Europa (3.3.2) with Eclipse-CDT (4.0.3).</p> diff --git a/files/ko/mozilla/developer_guide/eclipse/index.html b/files/ko/mozilla/developer_guide/eclipse/index.html deleted file mode 100644 index 5a1b2aae8a..0000000000 --- a/files/ko/mozilla/developer_guide/eclipse/index.html +++ /dev/null @@ -1,10 +0,0 @@ ---- -title: Eclipse -slug: Mozilla/Developer_guide/Eclipse -tags: - - NeedsTranslation - - TopicStub -translation_of: Mozilla/Developer_guide/Eclipse ---- -<p>There are versions of eclipse for several of the different languages that are used by Mozilla.</p> -<p>For documentation on using Eclipse CDT for Mozilla C/C++ development, see the <a href="/en/Eclipse_CDT" title="en/Eclipse_CDT">Eclipse CDT</a> page.</p> diff --git a/files/ko/mozilla/developer_guide/index.html b/files/ko/mozilla/developer_guide/index.html deleted file mode 100644 index e497c4143a..0000000000 --- a/files/ko/mozilla/developer_guide/index.html +++ /dev/null @@ -1,92 +0,0 @@ ---- -title: 개발자 가이드 -slug: Mozilla/Developer_guide -tags: - - Developing Mozilla - - NeedsTranslation - - TopicStub -translation_of: Mozilla/Developer_guide ---- -<p>당신이 숙련가이든 방금 시작했든, 이 페이지에 있는 글들은 당신이 모질라 개발을 할 수 있게끔 도와줄 것입니다.</p> - -<table class="topicpage-table"> - <tbody> - <tr> - <td> - <h2 class="Documentation" id="Documentation_topics">Documentation topics</h2> - - <dl> - <dt><a href="/en-US/docs/Introduction" title="Introduction">시작하기</a></dt> - <dd>A step-by-step beginner's guide to getting involved with Mozilla.</dd> - </dl> - - <dl> - <dt><a class="internal" href="/en-US/docs/Developer_Guide/Source_Code" title="en-US/docs/Developer_Guide/Source_Code">Working with Mozilla Source Code</a></dt> - <dd>A code overview, how to get the code, and the coding style guide.</dd> - <dt><a class="internal" href="/en-US/docs/Developer_Guide/Build_Instructions" title="en-US/docs/Developer_Guide/Build_Instructions">Build Instructions</a></dt> - <dd>How to build Firefox, Thunderbird, SeaMonkey, or other Mozilla applications.</dd> - <dt><a href="/en-US/docs/Developer_Guide/Development_process_overview" title="en-US/docs/Developer Guide/Development process overview">Development process overview</a></dt> - <dd>An overview of the entire Mozilla development process.</dd> - <dt><a href="/en-US/docs/Mozilla/Multiple_Firefox_Profiles" title="en-US/docs/Mozilla/Multiple_Firefox_Profiles">Managing multiple profiles</a></dt> - <dd>When working with prerelease versions of Firefox, it's often helpful to have multiple Firefox profiles, such as one for each channel, or for different kinds of testing.</dd> - <dt><a class="internal" href="/en-US/docs/Mozilla_automated_testing" title="en-US/docs/Mozilla automated testing">Automated Testing</a></dt> - <dd>How to run Mozilla's automated tests, and how to write new tests.</dd> - <dt><a class="internal" href="/en-US/docs/Developer_Guide/How_to_Submit_a_Patch" title="en-US/docs/Getting your patch in the tree">How to submit a patch</a></dt> - <dd>After getting your patch written, you need to get it checked into the tree. This article explains the review process and how to get your patch approved.</dd> - <dt><a href="/en-US/docs/Developer_Guide/Getting_documentation_updated" title="en-US/docs/Developer_Guide/Getting documentation updated">Getting documentation updated</a></dt> - <dd>How to ensure that documentation is kept up to date as you develop.</dd> - <dt><a class="internal" href="/en-US/docs/Mozilla_Modules_and_Module_Ownership" title="en-US/docs/Mozilla Modules and Module Ownership">Mozilla modules and module ownership</a></dt> - <dd>This article provides information about Mozilla's modules, what the role of a module owner is, and how module owners are selected.</dd> - <dt><a class="internal" href="/en-US/docs/Code_snippets" title="en-US/docs/Code_snippets">Code snippets</a></dt> - <dd>Useful code samples for a wide variety of things you might need to figure out how to do.</dd> - <dt><a class="internal" href="/en-US/docs/Mozilla_Development_Strategies" title="en-US/docs/Mozilla Development Strategies">Mozilla development strategies</a></dt> - <dd>Tips for how to make the most of your time working on the Mozilla project.</dd> - <dt><a class="internal" href="/en-US/docs/Debugging" title="en-US/docs/Debugging">Debugging</a></dt> - <dd>Find helpful tips and guides for debugging Mozilla code.</dd> - <dt><a href="/en-US/docs/Performance" title="en-US/docs/Performance">Performance</a></dt> - <dd>Performance guides and utilities to help you make your code perform well (and to play nicely with others).</dd> - <dt><a class="internal" href="/en-US/docs/The_Mozilla_platform" title="en-US/docs/The Mozilla platform">The Mozilla platform</a></dt> - <dd>Information about the workings of the Mozilla platform.</dd> - <dt><a href="/en-US/docs/Developer_Guide/Adding_APIs_to_the_navigator_object" title="en-US/docs/Developer_Guide/Adding_APIs_to_the_navigator_object">Adding APIs to the navigator object</a> {{ gecko_minversion_inline("9.0") }}</dt> - <dd>How to augment the {{ domxref("window.navigator") }} object with additional APIs.</dd> - <dt><a href="/en-US/docs/Developer_Guide/Interface_Compatibility" title="en-US/docs/Developer Guide/Interface Compatibility">Interface Compatibility</a></dt> - <dd>Guidelines for modifying scriptable and binary APIs in Mozilla.</dd> - <dt><a href="/en-US/docs/Developer_Guide/Customizing_Firefox" title="en-US/docs/Developer Guide/Customizing Firefox">Customizing Firefox</a></dt> - <dd>Information about creating customized versions of Firefox.</dd> - <dt><a href="/en-US/docs/Developer_Guide/Virtual_ARM_Linux_environment" title="Virtual ARM Linux environment">Virtual ARM Linux environment</a></dt> - <dd>How to set up an ARM emulator running Linux for testing ARM-specific, but not necessarily platform-specific, code. Useful for mobile developers.</dd> - <dt><a href="/en-US/docs/Introduction/Obsolete_Build_Caveats_and_Tips" title="Obsolete Build Caveats and Tips">Obsolete Build Caveats and Tips</a></dt> - <dd>A place to put build tips which are no longer relevant to building the latest version of the code from main but are relevant when building old codebases.</dd> - </dl> - </td> - <td> - <h2 class="Tools" id="Tools">Tools</h2> - - <dl> - <dt><a class="link-https" href="https://bugzilla.mozilla.org/" title="https://bugzilla.mozilla.org/">Bugzilla</a></dt> - <dd>The <a class="internal" href="/en-US/docs/Bugzilla" title="en-US/docs/Bugzilla">Bugzilla</a> database used to track issues for Mozilla projects.</dd> - <dt><a class="external" href="http://mxr.mozilla.org/" title="http://mxr.mozilla.org/">MXR</a></dt> - <dd>Browse and search the Mozilla source code repository on the Web.</dd> - <dt><a class="external" href="http://bonsai.mozilla.org/cvsqueryform.cgi" title="http://bonsai.mozilla.org/cvsqueryform.cgi">Bonsai</a></dt> - <dd>The <a class="internal" href="/en-US/docs/Bonsai" title="en-US/docs/Bonsai">Bonsai</a> tool lets you find out who changed what file in the repository, and when they did it.</dd> - <dt><a class="internal" href="/en-US/docs/Mercurial" title="en-US/docs/Mercurial">Mercurial</a></dt> - <dd>The distributed version-control system used to manage Mozilla's source code.</dd> - <dt><a class="external" href="http://tinderbox.mozilla.org/showbuilds.cgi" title="http://tinderbox.mozilla.org/showbuilds.cgi">Tinderbox</a></dt> - <dd><a class="internal" href="/en-US/docs/Tinderbox" title="en-US/docs/Tinderbox">Tinderbox</a> shows the status of the tree (whether or not it currently builds successfully). Check this before checking in and out, to be sure you're working with a working tree.</dd> - <dt><a class="internal" href="/en-US/docs/Crash_reporting" title="en-US/docs/Crash reporting">Crash tracking</a></dt> - <dd>Information about the <a class="link-https" href="https://crash-reports.mozilla.com/reports" title="https://crash-reports.mozilla.com/reports">Socorro</a> and <a class="external" href="http://talkback-public.mozilla.org/search/start.jsp" title="http://talkback-public.mozilla.org/search/start.jsp">Talkback</a> crash reporting systems.</dd> - <dt><a class="external" href="http://graphs.mozilla.org/" title="http://graphs.mozilla.org/">Performance tracking</a></dt> - <dd>See performance information for Mozilla projects.</dd> - <dt><a href="/en-US/docs/Developer_Guide/Callgraph" title="en-US/docs/Developing Mozilla/Callgraph">Callgraph</a></dt> - <dd>A tool to help perform static analysis of the Mozilla code by generating callgraphs automatically.</dd> - <dt><a class="external" href="http://www.mozilla.org/community/developer-forums.html" title="http://www.mozilla.org/community/developer-forums.html">Developer forums</a></dt> - <dd>A topic-specific list of discussion forums where you can talk about Mozilla development issues.</dd> - <dt><a class="external" href="http://www.brianbondy.com/mozilla/cheatsheet/" title="http://www.brianbondy.com/mozilla/cheatsheet/">Mozilla Platform Development Cheat Sheet</a></dt> - <dd>Brian Bondy's list of frequently referenced information for platform developers.</dd> - </dl> - </td> - </tr> - </tbody> -</table> - -<p> </p> diff --git a/files/ko/mozilla/developer_guide/mozilla_build_faq/index.html b/files/ko/mozilla/developer_guide/mozilla_build_faq/index.html deleted file mode 100644 index f4f6e3ee52..0000000000 --- a/files/ko/mozilla/developer_guide/mozilla_build_faq/index.html +++ /dev/null @@ -1,415 +0,0 @@ ---- -title: Mozilla Build FAQ -slug: Mozilla/Developer_guide/Mozilla_Build_FAQ -tags: - - Build documentation -translation_of: Mozilla/Developer_guide/Mozilla_build_FAQ ---- -<p>See also:</p> -<ul> - <li><a class="external" href="http://www.mozilla.org/build/win32-debugging-faq.html">Win32 Debugging FAQ</a>: Tips on how to debug Mozilla on Windows</li> -</ul> -<h3 id="General_questions" name="General_questions">General questions</h3> -<p> </p> -<p> </p> -<dl> - <dt id="platform"> - Which systems are supported Mozilla build platforms?</dt> - <dd> - There are multiple levels or tiers of Mozilla build "support". - <p>Tier-1 platform refers to platforms that are the primary focus for development. Major problems on these platforms are considered showstoppers. These are also the platforms that show up on the <a class="external" href="http://tinderbox.mozilla.org/showbuilds.cgi?tree=SeaMonkey">SeaMonkey tinderbox page</a>. The tier-1 platforms are:</p> - <ul> - <li>linux/x86 (gcc)</li> - <li>win32/x86 (msvc)</li> - <li>OS X (gcc)</li> - </ul> - <p>Tier-2 platforms are platforms for which a small varying subset of developers & contributors actively try to maintain but general development does not halt for problems on these platforms. These platforms are usually referred as the Ports as most of them reside on the <a class="external" href="http://tinderbox.mozilla.org/SeaMonkey-Ports/">SeaMonkey-Ports tinderbox page</a>. The tier-2 platforms are:</p> - <ul> - <li>aix 4.3 (aCC)</li> - <li>beos 5.0.3 (gcc)</li> - <li>bsdi 4.x (gcc)</li> - <li>hpux 10.x,11.x (HP cc)</li> - <li>irix 6.x/gcc (gcc/MIPSpro)</li> - <li>linux/ppc (gcc)</li> - <li>os/2 (gcc)</li> - <li>osf1 5.x (Compaq cc)</li> - <li>solaris (sparc & x86) 2.6+ (gcc/Forte)</li> - </ul> - <p>Tier-3 platforms are those platforms which generally are not actively worked on by the main developers of the project but have fixes contributed by third parties. Tier 3 platforms are:</p> - <ul> - <li>freebsd (gcc)</li> - <li>linux/alpha (gcc)</li> - <li>netbsd (gcc)</li> - <li>openvms (?)</li> - <li>ps2linux (gcc)</li> - <li>qnx 6 (gcc)</li> - <li>win32/x86 (gcc)</li> - </ul> - <p>All other platforms are "unsupported" by the primary mozilla developers, where "unsupported" really means "not a priority and no one is actively working on it".</p> - <p>Most Mozilla developers do not have access to non-tier-1 platforms so any bugs reports against non-tier-1 platforms should be overflowing with information to help the owner of the bug determine the cause of the problem and the proper solution. If you can provide a patch and/or verify that the developer's patches work for your platform, that would help a lot towards getting your bugs fixed and checked into the tree.</p> - <p> </p> - </dd> - <dt> - What type of build system does Mozilla use?</dt> - <dd> - Mozilla uses a thin GNU configure layer on top of a legacy Netscape 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. - <p> </p> - </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. - <p> </p> - </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. - <p> </p> - </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. - <p> </p> - </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 OS9 support shortly after the Mozilla 1.3 release. - <p> </p> - </dd> - <dt> - Why not ant, tmake, scons or - <i> - insert your favorite build system here</i> - ?</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. - <p> </p> - </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>User:Benjamin Smedberg</a> to discuss the details of your proposal. - <p> </p> - </dd> - <dt> - Why doesn't Mozilla support autoconf 2.5x?</dt> - <dd> - 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>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 acceptible tradeoff. The sub-projects are also standalone projects and forking an entire codebase because of a build system incompatiblity is silly.</p> - <p> </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 {{ Bug(52990) }} for details. - <p> </p> - </dd> - <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. - <p> </p> - </dd> - <dt> - What is an objdir?</dt> - <dd> - 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 build for multiple configurations, including multiple platforms if you use a network filesystem, from a single source tree. It also avoid tainting your source tree so that you know that the files in your tree have not been modified by the build process. - <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> - <p> </p> - </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. No, <a class="external" href="http://www.vmlinux.org/joachim/mirror/www.objsw.com/CrossGCC/FAQ-4.html#ss4.9">Canadian Cross-Compiling</a> is not supported. - <p> </p> - </dd> - <dt> - Do parallel (make -j) builds work for Mozilla?</dt> - <dd> - 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>If you get obscure build errors when using parallel building (especially when using -j instead of -jN to run as many tasks in parallel as possible), try reducing the number of parallel tasks by decreasing N (or, if you used unlimited parallelism, add a small number N to -j).</p> - <p>Parallel building with -j4 and -j8 seems to work well.</p> - <p> </p> - </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. - <p> </p> - </dd> - <dt> - error: file '../../toolkit/locales/en-US/chrome/necko/contents.rdf' doesn't exist at ../../config/make-jars.pl line 418, <STDIN> line 9.</dt> - <dd> - You are trying to build Firefox without following the instructions on <a href="ko/Configuring_Build_Options">Configuring Build Options</a>. In particular, your mozconfig file <b>must</b> source the Firefox default mozconfig file: - <pre class="eval">. $topsrcdir/browser/config/mozconfig -# add your custom additional options here -</pre> - <p> </p> - </dd> - <dt> - Initial cvs checkout fails with the message: <tt>cvs {{ mediawiki.external('checkout aborted') }}: *PANIC* administration files missing</tt></dt> - <dd> - You cannot create a cvs tree under a directory named "CVS". This is a feature/bug of cvs. cvs expects to find certain administration files under the CVS directory and will complain if they are missing. - <p> </p> - </dd> - <dt> - Error: ../coreconf/rules.mk:406: target `c' doesn't match the target pattern</dt> - <dd> - You need make 3.80 and no other version like 3.81 - <p> </p> - </dd> -</dl> -<h3 id="Mac-specific_questions" name="Mac-specific_questions">Mac-specific questions</h3> -<p> </p> -<dl> - <dt> - Can I build a Mozilla application as a Universal Binary?</dt> - <dd> - Yes. See <a href="ko/Mac_OS_X_Universal_Binaries">Mac OS X Universal Binaries</a> for instructions. - <p> </p> - </dd> - <dt> - Does Mozilla build on UFS?</dt> - <dd> - Yes, since {{ Bug(157036) }} has been fixed. - <p> </p> - </dd> - <dt> - Does Mozilla run on UFS?</dt> - <dd> - Yes. - <p> </p> - </dd> - <dt> - Can I use CodeWarrior to compile the Mach-O build?</dt> - <dd> - No, CodeWarrior is dead. See {{ Bug(119589) }} for details. - <p> </p> - </dd> - <dt> - After rebuilding e.g. layout, how do I make my FirefoxDebug.app reflect that change?</dt> - <dd> - make -C browser/app.</dd> -</dl> -<p>For common Mac build errors and additional troubleshooting tips, see <a href="ko/Mac_OS_X_Build_Prerequisites#Troubleshooting">Troubleshooting</a> in <a href="ko/Mac_OS_X_Build_Prerequisites">Mac OS X Build Prerequisites</a>.</p> -<h3 id="Win32-specific_questions" name="Win32-specific_questions">Win32-specific questions</h3> -<p> </p> -<p> </p> -<dl> - <dt> - Is there a Microsoft Visual Studio project file to build Mozilla?</dt> - <dd> - No. You must use cygwin and GNU make. - <p> </p> - </dd> - <dt> - Can I run the build commands from cmd.exe?</dt> - <dd> - Yes. Make invokes the cygwin /bin/sh subshell to execute commands so it does not matter what shell is used to initially invoke make. - <p> </p> - </dd> - <dt> - Which version of cygwin's autoconf package do I need to use?</dt> - <dd> - Because of the incompatibilities between autoconf 2.1x and 2.5x, the cygwin maintainers wrote a wrapper script which will determine which version of autoconf your configure script needs and invoke that version of autoconf. You will need the autoconf(-wrapper) & autoconf-stable packages. See <a class="external" href="http://cygwin.com/ml/cygwin-announce/2001/msg00177.html" rel="freelink">http://cygwin.com/ml/cygwin-announce.../msg00177.html</a> for details. - <p> </p> - </dd> - <dt> - Microsoft tools (CL, LINK, RC) gives - <i> - file not found</i> - errors</dt> - <dd> - The INCLUDE and LIB environment variables are used by the Microsoft Visual C++ tools. They are ordinarily set up in vcvars32.bat. Depending on which modules you build, you may or may not need MFC and ATL. Below are paths that work if Visual C++ is installed at "C:\msvs": - <pre class="eval">set INCLUDE=C:\msvs\VC98\Include;C:\msvs\VC98\MFC\Include;C:\msvs\VC98\ATL\Include -set LIB=C:\msvs\VC98\Lib;C:\msvs\VC98\MFC\Lib -</pre> - <p> </p> - </dd> - <dt> - cvs fails with the message:</dt> - <dd> - <pre class="eval">cvs update: authorization failed: server XXXX rejected access -cvs update: used empty password; try "cvs login" with a real password -</pre> - <p>You are mixing wincvs and cygwin cvs. Use only one or the other.</p> - <p> </p> - </dd> - <dt> - cvs fails with the message:</dt> - <dd> - <pre class="eval">cvs [checkout aborted]: cannot rename file CVS/Entries.Backup to CVS/Entries: Permission denied -</pre> - <p>As of cygwin 1.3.13, ntsec is enabled by default. ntsec is cygwin's attempt to get a more UNIX like permission structure based upon the security features of Windows NT. The error message indicates that there's a mapping discrepancy between the unix permissions listed in cygwin's /etc/passwd file and those used by Windows NT. As a workaround, you can add "nontsec" to your CYGWIN environment variable. The proper fix would be to fix the mapping problem.</p> - <p> </p> - </dd> - <dt> - Make spits out an error about not being able to find a .dtd file</dt> - <dd> - You probably used WinZip to unpack the source archive. Don't do that. WinZip, by default, doesn't unpack 0 length files from tar.gz archives. Use another utility, or use the pull script to checkout the files that WinZip didn't extract. - <p> </p> - </dd> - <dt> - nsinstall or another native win32 program complains about a file not being found</dt> - <dd> - Check your cygwin mount table. Running the mount command should return something similar to: - <pre class="eval">c: on /cygdrive/c type user (binmode,noumount) -e: on /cygdrive/e type user (binmode,noumount) -c:\cygwin on / type system (textmode) -c:\cygwin\bin on /usr/bin type system (textmode) -c:\cygwin\lib on /usr/lib type system (textmode) -</pre> - <p>The build system expects that drive partitions are mounted using /cygdrive as the drive prefix. If c: or e: does not use /cygdrive as the drive prefix, then you cannot build Mozilla using those drives. You will need to manually mount the drive at the expected spot by using the command:</p> - <pre class="eval">mount -s "e:\" /cygdrive/e -</pre> - <p>binmode (unix lineendings) or textmode (dos lineendings) don't matter as long as you use an editor (emacs, msdev) which can handle the appropriate line endings.</p> - <p> </p> - </dd> - <dt> - xpidl.exe crashes with an access violation</dt> - <dd> - This usually occurs because of a mismatch between your compiler and your glib and/or libIDL libraries. - <p>If you are building with Visual Studio .NET, then you must link against the VC7 built version of the glib & libIDL DLLs. For Visual Studio .NET 2003, use the VC7.1 versions. For Visual Studio 2005, use the VC8 versions.</p> - <p>The directory containing the versions of these libraries specific to your compiler must be in your PATH before any other version of those libraries. The .dll and .lib files must be executable (just chmod 755 them) or cygwin will not load them.</p> - <p>See <a href="ko/Windows_Build_Prerequisites/Free_Microsoft_Compilers">Windows Build Prerequisites</a> for more tips on building with VC7 and newer.</p> - <p>There are also some alternative static libraries available in {{ Bug(242870) }} that may be used instead of compiler specific libraries.</p> - <p>If you are building with VC6, then you must make sure that you are - <i> - not</i> - using the VC7 libraries at buildtime or at runtime.</p> - <p> </p> - </dd> - <dt> - configure: error: the linker major version, , does not match the compiler suite version, 6.</dt> - <dd> - The cygwin tool "link.exe" is being confused for an object linker. Make sure that the Microsoft tools are before cygwin in your PATH, or rename or remove /bin/link.exe - <p> </p> - </dd> - <dt> - configure: error: installation or configuration problem: C compiler cannot create executables.</dt> - <dd> - Try checking to make sure your PATH variable includes all the necessary directories. If you are using MS Visual Studio, run vcvars32.bat (which sets your PATH, LIB, and INCLUDE variables). 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. - <p> </p> - </dd> - <dt> - fatal error LNK1112: module machine type 'IA64' conflicts with target machine type 'X86'</dt> - <dd> - Try changing the order of the directories in your PATH, LIB, and INCLUDE variables. Move any directories that include "win64" or "IA64" (or "AMD64") closer to the end. - <p> </p> - </dd> - <dt> - LINK : fatal error LNK1104: cannot open file 'atlthunk.lib'</dt> - <dd> - According to <a class="external" href="http://forums.microsoft.com/msdn/ShowPost.aspx?PostID=64509">this Microsoft forum thread</a>, there is a different version of the Active Template Library (ATL) in the free Platform Software Development Kit (PSDK) than in Visual Studio. The ATL in the PSDK does not support 32-bit code, only 64-bit, whereas the Visual Studio ATL supports both and does not require atlthunk.lib. Apparently the atlthunk.lib file is not available and cannot be built from <a href="ko/Windows_Build_Prerequisites/Free_Microsoft_Compilers">freely available tools</a>, including the Visual C++ Toolkit and Visual Studio Express. You can either upgrade to the full version of Visual Studio to use its version of ATL, or you can workaround this problem by changing some code in atlbase.h (in \include\atl under the PSDK directory) as follows. - <pre class="eval">--- atlbase.h.old 2006-06-08 08:20:26.671875000 -0400 -+++ atlbase.h 2006-06-08 08:13:26.578125000 -0400 -@@ -283,7 +283,7 @@ - } - }; - #pragma pack(pop) -- -+/* - PVOID __stdcall __AllocStdCallThunk(VOID); - VOID __stdcall __FreeStdCallThunk(PVOID); - -@@ -291,6 +291,11 @@ - #define FreeStdCallThunk(p) __FreeStdCallThunk(p) - - #pragma comment(lib, "atlthunk.lib") -+*/ -+ -+// workaround for not having atlthunk.lib in PSDK or VC++ 2005 Express Edition -+#define AllocStdCallThunk() HeapAlloc(GetProcessHeap(),0,sizeof(_stdcallthunk)) -+#define FreeStdCallThunk(p) HeapFree(GetProcessHeap(), 0, p) - - #elif defined (_M_AMD64) - #pragma pack(push,2) -</pre> - <p>I also had to delete the object directory and compile from scratch in order for the compiler to pick up this change.</p> - <p> </p> - </dd> - <dt> - compiling or building an executable with cygwin and VS6.0 results in FIND: Parameter format not correct</dt> - <dd> - There is confusion between System32 "find" and cygwin's /usr/bin/find. The desired find is cygwin's. This is caused by Path ordering. A few possible solutions are possible: - <ul> - <li>temporarily rename system32/find.exe</li> - <li>make sure cygwin path entry comes before system32 path entry</li> - </ul> - <p> </p> - </dd> - <dt> - I packaged Firefox via the installer: <tt>make -C ${OBJ_DIR}/browser/installer installer</tt> without any problems. Executing the resulting installer asks for a missing mozz.dll; installation fails</dt> - <dd> - Both Thunderbird and Firefox should be compiled with the --enable-static --disable-shared configure flags - <p> </p> - <p> </p> - </dd> - <dt> - build fails with the message:</dt> - <dd> - <pre class="eval">shlibsign.exe - Entry Point Not Found -The procedure entry point CERT_GetFirstEmailAddress could not -be located in the dynamic link library nss3.dll. -</pre> - <p>You may have multiple instances of nss3.dll on your machine and in your path. Run a seach on your machine for all instances of this file. Move any instances found outside of your firefox build tree aside during the build and rename them back when the build is done.</dd></p> - <p> </p> - </dd> -</dl> -<h3 id="Unix-specific_questions" name="Unix-specific_questions">Unix-specific questions</h3> -<p> </p> -<dl> - <dt> - Galeon needs libgtksuperwin.so but I don't have that file in my Mozilla gtk2 builds. Where is it?</dt> - <dd> - Only the Mozilla gtk1 builds build libgtksuperwin.so. If you want to use galeon with a gtk2 build, you will need to use galeon2. - <p> </p> - </dd> - <dt> - Why does configure say that it needs libIDL >= 0.6.3 when I have libIDL 0.8.x installed?</dt> - <dd> - libIDL 0.8x can only be used when compiling against gtk2. Mozilla compiles against gtk1 by default. To use libIDL 0.8.x and gtk2, you must specify --enable-default-toolkit=gtk2 on the configure command line or in your mozconfig file. NOTE: This is an old issue which has been fixed for mozilla 1.8. - <p> </p> - </dd> - <dt> - How do I build on Solaris 10 x86 (Seamonkey)?</dt> - <dd> - I had to do the following to get a working environment</dd> - <dd> - 1. Install forte (free from Sun)</dd> - <dd> - 2. Install gmake (from blastwave)</dd> - <dd> - 3. mv /usr/ucb/cc /usr/ucb/cc.hold</dd> - <dd> - 4. CFLAGS="-xlibmil"; export CFLAGS</dd> - <dd> - 5. CXXFLAGS="-xlibmil -xlibmopt -features=tmplife -norunpath"; export CXXFLAGS</dd> - <dd> - 6. LDFLAGS='-R$ORIGIN -R/usr/sfw/lib -R/opt/sfw/lib -R/usr/local/lib -R/opt/csw/lib'; export LDFLAGS</dd> - <dd> - 7. PATH=$PATH:/opt/SUNWspro/bin:/opt/csw/bin:/opt/csw/sbin:/usr/ucb/bin:/usr/ccs/bin; export PATH</dd> - <dd> - 8. LD_LIBRARY_PATH=/opt/SUNWspro/lib:$LD_LIBRARY_PATH; export LD_LIBRARY_PATH</dd> - <dd> - 9. Create a mozconfig file and build as normal</dd> - <dd> - 10. The building of the package (tar and gzip) failed so I just manually tarred up the resulting files in the dist directory - <p> </p> - </dd> - <dt> - libxpcom_core.so: cannot restore segment prot after reloc: Permission denied</dt></dt> - <dd> - You are probably using Fedora Core 5, or some other Linux distrobution that has SELinux turned on. Use the command 'chcon -t chcon -t texrel_shlib_t lib*' in your dist/bin directory to fix it.</dd></dd> -</dl> -<p>{{ languages( { "fr": "fr/FAQ_sur_la_compilation_de_Mozilla" } ) }}</p> diff --git a/files/ko/mozilla/developer_guide/source_code/cvs/index.html b/files/ko/mozilla/developer_guide/source_code/cvs/index.html deleted file mode 100644 index 81325c1507..0000000000 --- a/files/ko/mozilla/developer_guide/source_code/cvs/index.html +++ /dev/null @@ -1,137 +0,0 @@ ---- -title: Mozilla Source Code Via CVS -slug: Mozilla/Developer_guide/Source_Code/CVS -original_slug: Mozilla_Source_Code_Via_CVS ---- -<p>Those doing active development can check out the latest source using CVS. This is the preferred method if you plan to provide patches and fix bugs, as it lets you get up-to-the-minute changes and merge them with your own.</p> -<p>If you want to compile a product for release, it is generally better to <a href="ko/Download_Mozilla_Source_Code">Download Mozilla Source Code</a> tarballs.</p> -<h3 id="Quick_Start_Guide" name="Quick_Start_Guide">Quick Start Guide</h3> -<p><span class="comment">I seem to not be editing this page in what others on this development site deem appropriate. So, if you are going to just remove this section, can you please be so kind as to suggest an alternate title of a new page that I can put this information on? Thanks, Jeff Carr</span></p> -<p>The basic steps to checkout the trunk (unstable) Firefox sources are:</p> -<pre class="eval">cvs -d <a class="link-mailto" href="mailto::pserver:anonymous:anonymous@cvs-mirror.mozilla.org" rel="freelink">:pserver:anonymous:anonymous@cvs-mirror.mozilla.org</a>:/cvsroot co mozilla/client.mk -cd mozilla -make -f client.mk checkout MOZ_CO_PROJECT=browser -</pre> -<p>Note that on Windows, your source tree must be located at a /cygdrive/<c> mount point. It must not be located within your /home.</p> -<h3 id="Getting_Started" name="Getting_Started">Getting Started</h3> -<p>CVS means "Concurrent Versioning System". To learn more about CVS in general, visit <a class="external" href="http://ximbiot.com/cvs/manual/">ximbiot.com</a>, or read the <a class="external" href="http://ximbiot.com/cvs/cvshome/docs/blandy.html">tutorial</a>.</p> -<p>Anyone can check out (also known as "pull" or "download") the sources via CVS, but only certain people have the ability to check in (make changes, also known as "commit"). Those people are the <a class="external" href="http://www.mozilla.org/owners.html">module owners</a> and their delegates. Read our document on <a class="external" href="http://www.mozilla.org/hacking/">hacking mozilla</a> to find out how to get the ability to check in. You may also wish to read about <a class="external" href="http://www.mozilla.org/cvs-ssh-faq.html">using SSH to connect to CVS</a>.</p> -<h4 id="Requirements" name="Requirements">Requirements</h4> -<p>To check out the sources, you need to be running <a class="external" href="http://www.nongnu.org/cvs/">CVS</a> 1.11 or later. 1.12.13 does not work with the CVS server, and instead results in hangs, although 1.12.9 is known to work. Furthermore, you must use <a class="external" href="http://www.gnu.org/software/make/">GNU make</a> to check out and build Mozilla. No other "make" program is acceptable. On windows, mac and regular GNU systems (like GNU/Linux), use "make" to run GNU make; on most non-GNU unixes (like e.g. Solaris, etc.), use "gmake".</p> -<h3 id="CVS_Client_Settings" name="CVS_Client_Settings">CVS Client Settings</h3> -<p>The "cvsroot" (repository identification string) used for anonymous access to Mozilla CVS is</p> -<pre class="eval"><a class="link-mailto" href="mailto::pserver:anonymous:anonymous@cvs-mirror.mozilla.org" rel="freelink">:pserver:anonymous:anonymous@cvs-mirror.mozilla.org</a>:/cvsroot -</pre> -<p>If you are using a graphical CVS interface, use the following server data:</p> -<ul> - <li><b>host</b>: "cvs-mirror.mozilla.org"</li> - <li><b>repository path</b>: "/cvsroot"</li> - <li><b>user</b>: "anonymous"</li> - <li><b>password</b>: "anonymous"</li> - <li><b>connection type</b>: pserver</li> - <li><b>port</b>: default (2401)</li> -</ul> -<h3 id="Selecting_a_Project_to_Pull" name="Selecting_a_Project_to_Pull">Selecting a Project to Pull</h3> -<p>Since several different applications are built from the same basic source code, you must choose which application to checkout on the command line using the <code>MOZ_CO_PROJECT</code> variable. This information has to be supplied when it comes to the checkout of the actual source code (see the appropriate <a href="#Checkout">checkout</a> <a href="#Checkout_2">section</a> below, according to the branch you want to checkout). The possible options include the following:</p> -<dl> - <dt> - browser </dt> - <dd> - The standalone "Firefox" browser.</dd> - <dt> - mail </dt> - <dd> - The standalone "Thunderbird" mail/news client.</dd> - <dt> - suite </dt> - <dd> - The traditional "Mozilla" SeaMonkey suite of browser, mail/news, composer, and other applications.</dd> - <dt> - minimo </dt> - <dd> - The standalone browser for small devices.</dd> - <dt> - composer </dt> - <dd> - The standalone HTML composer.</dd> - <dt> - calendar </dt> - <dd> - The standalone "Sunbird" calendar app.</dd> - <dt> - xulrunner </dt> - <dd> - The next-generation XUL application launcher.</dd> - <dt> - macbrowser </dt> - <dd> - The "Camino" native browser for Macintosh.</dd> - <dt> - all </dt> - <dd> - Check out sources for all of the above projects, plus some additional utility code</dd> -</dl> -<p>Multiple projects can be specified with commas: <code>MOZ_CO_PROJECT=suite,browser,xulrunner</code>.</p> -<p><b>Note</b> that if you are using a custom <tt><a href="ko/Configuring_Build_Options#Using_a_.mozconfig_Configuration_File">.mozconfig</a></tt> file, you can also specify <code>MOZ_CO_PROJECT</code> there, instead of including it on the command line.</p> -<h3 id="Checking_Out_a_New_Source_Tree" name="Checking_Out_a_New_Source_Tree">Checking Out a New Source Tree</h3> -<h4 id="Check_Tinderbox" name="Check_Tinderbox">Check Tinderbox</h4> -<p>Before pulling a tree, you should always check the appropriate <a href="ko/Tinderbox">Tinderbox</a> to make sure that the codebase is not broken. If there are red tinderboxes, it is usually advisable to wait until they are green before pulling a tree.</p> -<h4 id="Branch_HEAD" name="Branch_HEAD">Branch HEAD</h4> -<p>To check out a new source tree from scratch, get the <tt>client.mk</tt> file which contains makefile instructions which are used to pull the rest of the tree:</p> -<pre class="eval">$ cvs -d <a class="link-mailto" href="mailto::pserver:anonymous:anonymous@cvs-mirror.mozilla.org" rel="freelink">:pserver:anonymous:anonymous@cvs-mirror.mozilla.org</a>:/cvsroot co mozilla/client.mk -</pre> -<p>Note: if you have already set up a <tt><a href="ko/Configuring_Build_Options#Using_a_.mozconfig_Configuration_File">.mozconfig</a></tt> file, you may also need to check out the following files:</p> -<dl> - <dt> - Firefox </dt> - <dd> - <pre>cvs -d :pserver:anonymous:anonymous@cvs-mirror.mozilla.org:/cvsroot co mozilla/browser/config/mozconfig</pre> - </dd> - <dt> - Thunderbird </dt> - <dd> - <pre>cvs -d :pserver:anonymous:anonymous@cvs-mirror.mozilla.org:/cvsroot co mozilla/mail/config/mozconfig</pre> - </dd> -</dl> -<h4 id="Specific_Branch" name="Specific_Branch">Specific Branch</h4> -<p>If you want to check out the source code of a specific <a class="external" href="http://ximbiot.com/cvs/wiki/index.php?title=CVS--Concurrent_Versions_System_v1.12.12.1:_Branching_and_merging">CVS branch</a>, use</p> -<pre class="eval">$ cvs -d <a class="link-mailto" href="mailto::pserver:anonymous:anonymous@cvs-mirror.mozilla.org" rel="freelink">:pserver:anonymous:anonymous@cvs-mirror.mozilla.org</a>:/cvsroot co -r BRANCH mozilla/client.mk -</pre> -<p>instead. To, for example, pull the Firefox 2.0 development branch, replace BRANCH above with MOZILLA_1_8_BRANCH. For available branch tags in Mozilla, see <a href="ko/CVS_Tags">CVS Tags</a>.</p> -<p>The information on pulling project specific <code>.mozconfig</code> files as listed in the <a href="#Branch_HEAD">previous section</a> apply to other branches than HEAD as well of course.</p> -<h4 id="Checkout" name="Checkout">Checkout</h4> -<p>After having chosen the correct branch, run:</p> -<pre class="eval">$ cd mozilla -$ make -f client.mk checkout MOZ_CO_PROJECT=<i>option,option</i> -</pre> -<p>As mentioned above, if you are using a custom <code>.mozconfig</code> file where you have already specified the <code>MOZ_CO_PROJECT</code> variable, you do not need to repeat it here on command line.</p> -<div class="note"> - Always use <tt>client.mk</tt> to checkout the Mozilla sources: do not check out the <tt>mozilla/</tt> module directly. Various subprojects such as NSS, NSPR, and LDAP C SDK are pulled from stable release tags, even when regular mozilla development occurs on the trunk.</div> -<h3 id="Updating_a_Source_Tree" name="Updating_a_Source_Tree">Updating a Source Tree</h3> -<h4 id="Branch_HEAD_2" name="Branch_HEAD_2">Branch HEAD</h4> -<p>In order to update a source tree (be it branch HEAD or a specific branch) to latest branch HEAD, run:</p> -<pre class="eval">$ cd mozilla -$ cvs up -A client.mk -</pre> -<p>The -A option removes any "sticky branch" information, which leads to the effect that the tree is updated to HEAD.</p> -<h4 id="Specific_Branch_2" name="Specific_Branch_2">Specific Branch</h4> -<p>To update a source tree which was pulled from a specific branch, use</p> -<pre class="eval">$ cd mozilla -$ cvs up -r BRANCH client.mk -</pre> -<p>instead. Replace BRANCH by the tag of the branch you want to update.</p> -<h4 id="Checkout_2" name="Checkout_2">Checkout</h4> -<p>Having updated client.mk, you can do the checkout:</p> -<pre class="eval">$ make -f client.mk checkout MOZ_CO_PROJECT=<i>option,option</i> -</pre> -<p>As always, if you use a custom <code>.mozconfig</code> file where <code>MOZ_CO_PROJECT</code> is already defined, you do not need to repeat it on command line.</p> -<h3 id="Creating_a_Diff_File" name="Creating_a_Diff_File">Creating a Diff File</h3> -<p>In order to create a diff of a single local file against the current file in the repository, use:</p> -<pre class="eval">$ cvs diff -u8p FILENAME -</pre> -<p>See <a href="ko/Creating_a_patch">Creating a patch</a> for more information.</p> -<h3 id="Converting_a_Downloaded_Source_Tree" name="Converting_a_Downloaded_Source_Tree">Converting a Downloaded Source Tree</h3> -<p>Downloaded source trees from mozilla.org (<a href="ko/Download_Mozilla_Source_Code">source tarballs</a>) are already set up with CVS information, like a normal checkout. You can update these trees like normal trees to the latest code, without special action. See previous section on how to update a source tree.</p> -<p><br> - <span class="comment">interwiki link</span></p> -<p>{{ languages( { "fr": "fr/Obtenir_le_code_source_de_Mozilla_via_CVS", "ja": "ja/Mozilla_Source_Code_Via_CVS", "zh-cn": "cn/\u901a\u8fc7CVS\u83b7\u53d6\u6e90\u7801" } ) }}</p> diff --git a/files/ko/mozilla/developer_guide/source_code/index.html b/files/ko/mozilla/developer_guide/source_code/index.html deleted file mode 100644 index 13120b58e7..0000000000 --- a/files/ko/mozilla/developer_guide/source_code/index.html +++ /dev/null @@ -1,49 +0,0 @@ ---- -title: Working with Mozilla source code -slug: Mozilla/Developer_guide/Source_Code -tags: - - Developing Mozilla - - NeedsTranslation -translation_of: Mozilla/Developer_guide/Source_Code ---- -<p>The articles below will help you get your hands on the Mozilla source code, learn to navigate the code, and how to get the changes you propose checked into the tree.</p> - -<div class="row topicpage-table"> -<div class="section"> -<dl> - <dt><a class="internal" href="/en-US/Developer_Guide/Source_Code/Mercurial" title="En/Mozilla Source Code (Mercurial)">Getting the code from the Mercurial repository</a></dt> - <dd>If you plan to contribute to the Mozilla project, the best way to get the code is to check it out from the version control repository. Learn how to do that here.</dd> - <dt><a href="https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Using_the_VM">Getting a pre-configured Mozilla build system virtual machine</a></dt> - <dd>This is the easiest way to get started: use a VirtualBox virtual machine which is already configured with a complete build environment for you to use. Just boot the VM and build!</dd> - <dt><a class="internal" href="/en-US/Developer_Guide/Source_Code/Downloading_Source_Archives" title="En/Mozilla Source Code (HTTP//FTP)">Downloading the source code</a></dt> - <dd>If you want to fetch the code for a specific release of a particular Mozilla product, you may prefer to download a source code archive.</dd> - <dt><a class="internal" href="/en/Viewing_and_searching_Mozilla_source_code_online" title="En/Viewing and searching Mozilla source code online">Viewing and searching Mozilla source code online</a></dt> - <dd>Learn how to use MXR, Mozilla's online search and browsing tool for accessing the source code. This isn't a good way to download the code, but is a great way to search it.</dd> - <dt><a class="internal" href="/en/Mozilla_Source_Code_Directory_Structure" title="en/Mozilla Source Code Directory Structure">Navigating the Mozilla source code</a></dt> - <dd>Learn about the various folders in the Mozilla source tree, and how to find what you're looking for.</dd> - <dt><a class="external" href="/en/Introduction#Find_a_bug_we%27ve_identified_as_a_good_fit_for_new_contributors." title="/en/Introduction#Find_a_bug_we%27ve_identified_as_a_good_fit__for_new_contributors.">Bugs for newcomers</a></dt> - <dd>If you are new to the project and want something to work on, look here.</dd> -</dl> -</div> - -<div class="section"> -<dl> - <dt><a class="internal" href="/en-US/Developer_Guide/Coding_Style" title="En/Mozilla Coding Style Guide">Mozilla Coding Style Guide</a></dt> - <dd>The code style guide provides information about how you should format your source code to ensure that you don't get mocked by the reviewers.</dd> - <dt><a href="/en-US/Developer_Guide/Interface_development_guide" title="En/Developer Guide/Interface development guide">Interface development guide</a></dt> - <dd>Guidelines and documentation for how to create and update XPCOM interfaces.</dd> - <dt><a href="/en-US/docs/Mozilla/Developer_guide/CSS_Guidelines">The Firefox codebase: CSS Guidelines</a></dt> - <dd>This document contains guidelines defining how CSS inside the Firefox codebase should be written, it is notably relevant for Firefox front-end engineers.</dd> - <dt><a href="/en-US/docs/Mozilla/Developer_guide/SVG_Guidelines">SVG Cleanup Guide</a></dt> - <dd>Guidelines and best practices for shipping new SVGs.</dd> - <dt><a class="link-https" href="https://wiki.mozilla.org/Build:TryServer" title="https://wiki.mozilla.org/Build:TryServer">Try Servers</a></dt> - <dd>Mozilla products build on at least three platforms. If you don't have access to them all, you can use the try servers to test your patches and make sure the tests pass.</dd> - <dt><a class="internal" href="/en/Creating_a_patch" title="En/Creating a patch">Creating a patch</a></dt> - <dd>Once you've made a change to the Mozilla code, the next step (after making sure it works) is to create a patch and submit it for review. <em>This article needs to be updated fully for Mercurial.</em></dd> - <dt><a class="external" href="https://www.mozilla.org/hacking/committer/" title="https://www.mozilla.org/hacking/committer/">Getting commit access to the source code</a></dt> - <dd>Feel ready to join the few, the proud, the committers? Find out how to get check-in access to the Mozilla code.</dd> - <dt><a class="internal" href="/en-US/Developer_Guide/Source_Code/CVS" title="En/Mozilla Source Code (CVS)">Getting older Mozilla code from CVS</a></dt> - <dd>Older versions of the Mozilla source code, as well as the current versions of NSS and NSPR, are kept in a CVS repository. Learn about that in this article.</dd> -</dl> -</div> -</div> |