~ubuntu-branches/debian/sid/eclipse-cdt/sid

« back to all changes in this revision

Viewing changes to results/plugins/org.eclipse.cdt.doc.user/concepts/cdt_c_discovery_options.htm

  • Committer: Package Import Robot
  • Author(s): Jakub Adam
  • Date: 2011-10-06 21:15:04 UTC
  • mfrom: (1.1.4)
  • Revision ID: package-import@ubuntu.com-20111006211504-8dutmljjih0zikfv
Tags: 8.0.1-1
* New upstream release.
* Split the JNI packages into a separate architecture dependent
  package and made eclipse-cdt architecture independent.
* Install JNI libraries into multiarch aware location
* Bumped Standards-Version to 3.9.2.

Show diffs side-by-side

added added

removed removed

Lines of Context:
1
 
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
2
 
<html lang="en">
3
 
 
4
 
<head>
5
 
        <meta http-equiv="Content-Language" content="en-us">
6
 
        <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
7
 
        <title>Views in the C/C++ perspective</title>
8
 
        <link rel="stylesheet" type="text/css" href="../help.css">
9
 
</head>
10
 
 
11
 
<body>
12
 
<h1>Discovery options</h1>
13
 
 
14
 
<p>For projects where the IDE generates a makefile to build the project automatically, the IDE has more information about the internal build state of the make project compared to those projects where you provide a makefile to build the project. 
15
 
 
16
 
<p>For example, a makefile includes build information and other settings, such as include file paths (-I) and macro definitions (-D), which are standard to the build tools (such as the compiler and linker). When the makefile is automatically created for you, this information is known to Eclipse to a greater extent then when you create and manage the makefile for a project yourself. The type of information affects the search capabilities and Code Assist abilities of Eclipse. Therefore, in this example, the purpose of Discovery Options is for improved search and Code Assist capability for projects where Eclipse does not manage the makefile for you. For example, in an open source file of an editor view, to see the declaration for a function that the code calls, you select the function, right click, and select <b>Open Declaration</b> from the context menu. If the location of the include file (that was coded in the makefile for the project) containing the function declaration was in some directory, the CDT would not find the declaration because it has no visibility for that include path. Consequently, you can use Discovery Options in the CDT to enhance the IDE build state by parsing the build process output to extract build path information that the CDT searching mechanism uses to locate and open the include file. By default, the CDT uses GNU* tools (gcc, etc.).  If you want to build your projects using another compiler, use the settings described here.</p>
17
 
 
18
 
<p>Scanner configuration discovery is tightly linked to project's build process. The first part of scanner discovery begins during the make build for make projects where you provide the makefile. The Eclipse CDT parses the build output for compiler commands with options that specify the definition of the preprocessor symbols and include search paths (for the gcc compiler, -D and -I), and then it stores the information as the project's discovered scanner configuration. 
19
 
 
20
 
<p>Next, after the build process completes, it is implemented as a separate Eclipse builder where it runs a generate scanner info command, and then parses the output (properties specified on the Discover Options tab for Builds in the Project Properties window). 
21
 
 
22
 
<p>For C++, the default generate scanner information command is <b>gcc -E -P -v myfile.c | myfile.cpp</b>. This command reads the compiler's configuration file and prints the information that includes compiler's internally defined preprocessor symbols and include search paths.
23
 
 
24
 
<p>A single scanner configuration is applicable to all the files in a project. Although Eclipse discovers the information for each compilation unit, it stores the scanner configuration on a per project basis. This means that Eclipse applies a single, cumulative scanner configuration to all files in a project. 
25
 
 
26
 
<p>The following situations identify circumstances when certain parts of the scanner configuration are in conflict:
27
 
        <ul>
28
 
                <li>Symbol definitions that contradict 
29
 
                <li>An incorrect order for the include paths
30
 
                <li>Internal scanner information may not be applicable to all the files in a project (for a single compiler), because some files might be compiled with a different compiler, or have target specific options specified.
31
 
        </ul>
32
 
</p>
33
 
        
34
 
<p><b>Note:</b> Only basic command line options are supported. In addition, only basic scanner configuration related command line options are recognized (for example, -D and -I for gcc). For some of the commands, their relative position in the command line is important. For information about these options, see the documentation for the utilities you are using.
35
 
 
36
 
<p><img border="0" src="../images/ngconcepts.gif" ALT="Related concepts" width="143" height="21">
37
 
<br><a href="cdt_c_over_cdt.htm">CDT Overview</a>
38
 
<br><a href="cdt_c_perspectives.htm">C/C++ perspectives</a>
39
 
</p>
40
 
 
41
 
 
42
 
<p><img border="0" src="../images/ngref.gif" ALT="Related reference" width="143" height="21">
43
 
<br><a href="../reference/cdt_o_views.htm">Views</a>
44
 
</p>
45
 
 
46
 
<p>
47
 
<img src="../images/rh03_04.gif" ALT="Red Hat Copyright Statement"><br>
48
 
<img src="../images/ng00_07.gif" ALT=" IBM Copyright Statement" >
49
 
</p>
50
 
</body>
51
 
 
52
 
</html>