CDT FAQ
frequently asked question and answers
|
CDT FAQ |
|
| CDT User FAQ | |
|
The following is the official CDT FAQ. This document is a work in progress -- feedback is appreciated. |
|
| Table of contents: |
Unable to instantiate editor: org.eclipse.cdt.ui.editor.CEDitor. org.eclipse.core.runtime.CoreException: Plug-in org.eclipse.cdt.ui was unable to load class org.eclipse.cdt.internal.ui.editor.CEditor.
| General |
 top
|
The CDT (C/C++ Development Tools) Project is working towards providing a fully functional C and C++ Integrated Development Environment (IDE) for the Eclipse platform.
There are a number of groups contributing to the CDT; We strongly encourage interested parties to extend our work, thereby making the Eclipse CDT project a richer set of freely available resources. We are looking for contributions from the open source community in the areas of test, development, documentation, and general users who can help us ensure that the C/C++ tools work well on all the Eclipse platforms.
Our current release function includes:
Default implementations of all interfaces and extension points will be supplied for various platforms.
The CDT is fully open-source and implemented purely in java as a set of plugins to the Eclipse platform. To learn more visit the CDT Home Page.
The CDT consists of software produced by the CDT team combined with third party software developed from other Open Source Projects. The software produced by the CDT team is licensed under the Common Public License. The software designed by third parties is made available under their respective licenses. Refer to the about.html file in the root directory of every CDT plugin for specific licensing information.
Visit CDT Project Structure to find out more about the organization of CDT (History, participants, and project structure).
The official CDT Development plans are here:
If you wish to contribute to the development of the CDT, we welcome the opportunity to work with you. The plans will be updated to reflect the commitments made by contributors to this projects. See Working on the CDT for information on how to get started.
Release Milestones (which represent planned availability dates for Stable CDT builds) are noted in the CDT Plan Documents which can be found on the CDT Overview Page. To see the currently available CDT builds, visit the CDT Download Page.
This is a bit of a moving target, but currently the compiler supported (from an error parsing point of view) is gcc, the debugger interface will work with gdb 5.2.1 (or higher) and the default build command is GNU "make".
The CDT Framework is platform independent. It will run where Eclipse will run. However, the default implementations may depend on external applications. To follow in the Eclipse spirit of open source, the default implementations rely upon freely available open source tools, such as the GNU Tools: GDB and Make. Therefore, the dependencies on GDB for debugging, or Make for building, will require that these applications are available for the platform that the user wishes to use. References to some of the known implementations for each platform will be indicated in the sections of this FAQ that include instructions for installation, project creation and building the CDT on the various platforms.
Which platforms are fully supported will ultimately depend on the needs of the community, as expressed by the participation in developing, and testing for each platform.
The core plugins are written in Java with no native code and thus may be ported to any platform supported by Eclipse. However, some default implementations may require that other software or tools, licensed under GNU, may be required.
In general there is some version of Linux and some version of windows used by the developers on the CDT. For an exact list of supported platforms see the Downloads page
NOTE: The CDT does NOT run on Windows 98 and Windows ME.
The objective is to support the CDT on all target operating environments listed in the Eclipse 3.0 Project Plan.
Eclipse SDK 3.0 is tested and validated on the following reference platforms (this list is updated over the course of the release cycle):
|
Eclipse Reference Platforms
|
|||
|---|---|---|---|
| Operating system | Processor architecture | Window system | Java 2 Platform |
| Microsoft Windows XP | Intel x86 | Win32 | * Sun Java 2 SDK, Standard Edition, version 1.4.2_03 for Microsoft Windows |
| Microsoft Windows XP | Intel x86 | Win32 | IBM 32-bit SDK for Windows, Java 2 Technology Edition, Version 1.4.1 |
| * Red Hat Enterprise Linux WS 3 | Intel x86 | GTK | * Sun Java 2 SDK, Standard Edition, 1.4.2_03 for Linux x86 |
| * Red Hat Enterprise Linux WS 3 | Intel x86 | GTK | IBM 32-bit SDK for Linux on Intel architecture, Java 2 Technology Edition, Version 1.4.1 |
| SuSE Linux 8.2 | Intel x86 | GTK | * Sun Java 2 SDK, Standard Edition, 1.4.2_03 for Linux x86 |
| SuSE Linux 8.2 | Intel x86 | GTK | IBM 32-bit SDK for Linux on Intel architecture, Java 2 Technology Edition, Version 1.4.1 |
| Sun Solaris 8 | SPARC | Motif | * Sun Java 2 SDK, Standard Edition, 1.4.2_03 for Solaris SPARC |
| HP HP-UX 11i | hp9000 PA-RISC |
Motif | * HP-UX SDK for the Java 2 platform, version 1.4.2.00 for hp9000 PA-RISC |
| * IBM AIX 5L Version 5.2 | PowerPC | Motif | IBM 32-bit SDK for AIX, Java 2 Technology Edition, Version 1.4.1 |
| * Apple Mac OS X 10.3 | PowerPC | Carbon | Java 2 Standard Edition 1.4.1 for Mac OS X |
| QNX Neutrino RTOS [version TBD] | Intel x86 | Photon | IBM J9 VM for QNX [version TBD] |
* Although untested, Eclipse should work fine on other OSes that support the same window system. For Win32: NT, 2000, and Server 2003; SWT HTML viewer requires Internet Explorer 5 (or higher). For GTK on other Linux systems: version 2.2.1 of the GTK+ widget toolkit and associated libraries (GLib, Pango); SWT HTML viewer requires Mozilla 1.4GTK2. For Motif on other Linux systems: Open Motif 2.1 (included); SWT HTML viewer requires Mozilla 1.4GTK2.
"Supported" has a particular meaning to us. It means that on that platform we have a good level of confidence that CDT works correctly and that its function is appropriate and complete. That means
The Framework supports all the platforms that Eclipse does. The CDT team is responsible for ensuring that this remains true for the framework. Specific default implementations will work only on platforms where the required applications are available. The following list is derived from the initial CDT meeting in July 2002. The following companies have agreed to provide support for the associated platforms:
| Platform | Company |
| QNX Neutrino | QNX Software Systems Ltd. |
| Linux | IBM, Red Hat |
| Windows | IBM, MontaVista with initial support from QNX |
If you have a favorite platform we highly encourage you to get involved and volunteer to own a feature that does not currently have an implementation that works on your platform of choice. See Working on the CDT for more information.
CDT related questions that are not answered in this FAQ or the documentation should be posted to the CDT newsgroup. You will need a password. You can also use this simple web interface to browse the newsgroup.
General Questions about the Eclipse SDK which includes the Eclipse Platform , JDT (Java Development Tools), or PDE (Plugin Development Environment) should be posted to the Eclipse newsgroup.Keep in mind that these newsgroups are public, so do not include any confidential information in your questions. You should also read "How to ask questions the smart way" by Eric Raymond before participating in the newsgroups. NOTE: Please submit bugs to bugzilla, not to the newsgroups. See the How do I report a bug or request a feature? section of this document.
People will still come into a newsgroup asking questions that have been answered before and often will not provide any information about what versions they have installed, and what the problem is. You will be much more likely to get help if you provide enough information to reproduce the problem. The section on how to report a bug gives a list of some information which could be useful.
The CDT Project (like the Eclipse Project) uses bugzilla as its bug and feature tracking system. Entering a bug\feature report is as simple as filling in a web form on the eclipse bugzilla page. The first time you enter a bug you will need to create a new bugzilla account for yourself by providing an email address and choosing a password.
Before entering a bug report, you should search bugzilla to see if someone else has already entered a bug report similar to yours. If you find a bug report that outlines the problem you are seeing, you can simply annotate it with your comments to let the developers know that you have also hit the bug. Also you can add yourself to the CC list of the bug so that you will notified when the status of the bug changes or someone adds comments.
Once you have searched bugzilla and not found anything, you can go ahead and enter a new bug report. Please read the bug writing guidelines located on the eclipse bug reporting page.
To make your bug report more helpful include the following in your bug reports:
Environmental settings:
Problem Description:
The .log file is located in the workspace/.metadata directory.
The .log file is used by the Eclipse Platform to log runtime errors. It is useful to include it in bug reports because it contains stack traces that occur in plug-ins. When you report a bug, make sure to include your .log file!
Feedback sent do the cdt-dev developer mailing list will be incorporated into future version of this FAQ.
The CDT Manuals are part of the CDT install. To view the books open Help Contents from the Help menu and then select a book from the combo box.
There is also some designer documentation on the CDT website.
| Download and Installation |
top
|
Check the CDT Download Page for information on which CDT Build to use. Currently the following builds are available there:
CDT 2.0
CDT 1.2
CDT 1.0
CDT 1.1
The best place to look for instructions is the CDT Download Page. However, here is a summary (which is probably out of date):
| CDT 1.2 Must have Eclipse 2.1.X installed |
CDT release builds are made available on the CDT release
update site. Use the following URL in a Site Bookmark in the update
manager: http://update.eclipse.org/tools/cdt/updates/new To access the Update Manager, select Software Updates->Update Manager from the Help menu. To access an update site, select New->Site Bookmark from the context menu in the Feature Updates view. In the New Site Bookmark dialog, enter a name for the site (any name) and enter the URL for the update site. You can then expand the site bookmark in the Feature Updates view to reveal the available downloads. Currently, CDT releases 1.2 and 1.1 are available as well as releases of CDT/CPPUnit Integration. As new releases are made and new features are added, they will appear in this update site. For those who need the flexibility of the old zip distributions, they are available here. |
|
| CDT 2.0 Requires Eclipse 3.0 |
The CDT 2.0 build is available from the following update site: http://update.eclipse.org/tools/cdt/releases/new To install the update in Eclipse 3.0, first uninstall any CDT version you happen to have currently installed. Then from the menu bar,
There are zip files available at this same link. |
|
The CDT is supported on the platforms specified on the download page. The downloads are structured and named to indicate, which OS and windowing system it runs on. If you do not see your OS/windowing system combination please contact us. We are always looking for volunteers to test and support platforms.
Much of the CDT default functionality uses applications that are available on most operating systems. The CDT leverages some default system tools such as gdb (debugging), make (building). These tools are available for many platforms and if they exist on your system, there is a good chance that the default functionality will work. See Compilers and other 3rd party tools for more information
The caveat is that the operation of the CDT on some operating systems has not been fully tested and we cannot commit time to fixing platform specific problems found on these platforms. However, code submissions from developers wanting to improve the CDT will always be gratefully accepted. See Working ON the CDT for more information.
We do not currently ship an uninstaller. You can uninstall the CDT manually:
Delete the following:
| C/C++ Project Creation |
top
|
This section will use an example to create the familiar "Hello World!" C++ program. First, ensure that you have the CDT installed within Eclipse, as described above. Open a C/C++ Perspective and complete the following steps:
Click Projects from the menubar and ensure there is no checkmark beside Build Automatically if there is one click Build Automatically to deselect it.
#include <stdio.h>
int main()
{
printf("Hello World\n");
//block until user types something
fgetc(stdin);
return 0;
}
Now, save the file.
This section will use an example to create the familiar "Hello World!" C++ program. First, ensure that you have the CDT installed within Eclipse, as described above. Open a C/C++ Perspective and complete the following steps:
#include <stdio.h>
int main()
{
printf("Hello World\n");
//block until user types something
fgetc(stdin);
return 0;
}
Now, save the file.
hello.exe : hello.o
g++ -o hello.exe hello.o
hello.o : hello.cpp
g++ -c hello.cpp
all : hello.exe
clean :
-rm hello.exe hello.o
Now, save the file.
If the source is accessible to the user from their desktop using the
command line then it is possible to simply make the root directories
containing that source as Eclipse projects. This is accomplished by invoking
the New Project Wizard, selecting C or C++ and then Standard Make Project as
the project type. On the next page, enter a name for the project, the
deselect the "Use Default Location" checkbox. This will let you Browse to
the root folder of the source tree. After setting other information and
clicking on Finish, the project will be created in the root of the source
folder you have selected.
The resource for the project are maintained in the remote location
specified, not in the workspace folder for eclipse. Meta data for the
project, such as the index for the project and the "link" to the project, is
stored in the metadata directory in the workspace folder.
If the existing source tree is managed in CVS, it is possible to use the CVS Repository perspective to "Checkout As Project" any folder in the repository. The first time this is done, a Simple Project is created for the folder. To access the features of the CDT for this project, the project must be converted to a C or C++ project using the "Convert to a C or C++ Project" project type in the New Wizard.
This does a CVS checkout of the project into the project's location (usually in the workspace).
Another approach would be to create the C/C++ Project and then do an "Import"->"File System". This will make a copy of the files from the selected location into the selected folder in the project. With the copy, this approach is more wasteful and detaches the source from any control mechanism that existed in the originally file location (e.g. a ClearCase view)
| Editing C/C++ Projects |
top |
Content Assist is a work in Progress. For CDT 2.0 you should be able to ask for code completion anywhere in your source file. If you fail to find a completion you expect to find, most probably this is because of a failure in parsing your source file. In this case, check that you have added the correct set of include paths to the project containing your source file.
For example in the following code:
int main() {
pr
}
You should not expect "pr" to provide "printf" as a completion unless:
As we improve and further develop the CDT, this function will get better and better.
Often when search is not behaving as expected, it is due to the CDT not having enough information available to parse the source files. For example, if you include a header file, but do not tell CDT about the directory where that header file exists, then it is unlikely that CDT will understand the contents of your source file.
The outline view does not respect macros and header contents. It is simply a file view. This may not be what you desire.
In general the parser needs to know the include paths and macro definitions for each source file and the compiler built-ins before it can be parsed(the indexer is one client that will parse the files).
In CDT there is a scanner config feature that will invoke the compiler "gcc -E -P -v -dD" to ask it for the default values. This feature will also look at the output of running "make" and try to determine which includes (-I) and which defines (-D) have bee set on the command line.
Your project has been setup to use the defaults for gnu to get this info. Since you are using a non-gnu compiler, you should disable all of the discovery feature. Got to the Properties on your project and open the section "C/C++ Make project" and select the "Discovery Options" tab. Deselect the "Automate discovery of paths and symbols" and these errors will go away.
Note that you will then need to manually add the paths and symbols to the project (or you will get a lot of other parser errors). This can be done from the same dialog under "C/C++ Include paths and symbols".
Go to
Preferences -> Workbench -> Editors -> File Associations
and add a new File Association xyz
| Compilers and other 3rd party tools |
top |
In order to build your C++ code and debug your C++ executable, you will need to get a compiler, a make program and a debugger.
There are several tools that can help you run GNU Tools on Windows.
Both of these tools offer a selection of GNU tools such as gcc, gdb and make.
For example, on Windows you can install the Cygwin toolkit which is a Unix environment for Windows and includes automake and gdb.
Note:
The CDT currently uses GDB version 5.2.1 and later.
The current CDT doesn't integrate with a specific toolchain, but rather integrates with a build command, such as make, nmake, jam ant etc and this build command drives the toolchain. The default build command is make, but can be configured via the project properties:
CDT however, will generate a makefile for you (if you want it to). See When do I use the managed make feature. Currently the default toolchain for this feature is g++, make, and gdb. See How do I add support for my toolchain via the managed build feature for information on adding other toolchains to this feature.
There is documentation available as Managed Build Extensibility Reference Document. Please feel free to provide feedback on this doc to the cdt-dev mailing list.
No. CDT is only the IDE part of Eclipse. It doesn't provide any compiler toolchain nor C++ libraries, as these are part of the compilers and the operating system etc.
| Building C/C++ Projects |
top |
When you already have a makefile and you wish to use it.
When you do not have a makefile, and do not want to write one, the managed make feature will be able to generate one for you. Note that the current CDT (1.2.1 and 2.0) generates makefiles that use GNU gcc and g++. If you are not using this compiler, (and you do not have a managed make plugin for your compiler), then you will need to use the standard make feature.
Bugzilla Bug 71443. The Build Automatically flag removes the build menus.
For C/C++ projects this feature should be turned off, otherwise builds will be performed whenever a file is saved, including makefiles and header files.
Click Projects from the menubar and ensure there is no checkmark beside Build Automatically if there is one click Build Automatically to deselect it.
You should now be able to Build and Clean a project.
The C-Build view is a console which shows all of the activity which occurs once a project's build command is executed.
This usually indicates that "make" is not on your path. Open a command window and type "make". If you receive the equivalent of "command not found" then you will need to ensure that the location of the make executable is on your path. (If you have changed your build command to something else, like "mingw32-make -f makefile" then this something else needs to be on your path.)
Note that the managed build project will always use "make.exe". If make.exe does not exist it will not work.
This message usually indicates that the a tool called from inside the makefile is not found (on the path). If the error looks like the following, then "gcc" could not be found:
gcc -c hello.c
Process begin: CreateProcess((null), gcc -c hello.c, ...) failed.
make (e=2): The system cannot find the file specified.
You will need to ensure that the path to the executable "gcc" is on your path.
The ManagedBuilder does not respect the src paths when generating the makefile (as of CDT 2.0). However, there is a hack to prevent the generated makefile from building files.
To remove the file "devices/devices.c[pp]" from the build, add a file named "makefile.defs" to the project ROOT and added the following lines to it:
OBJS := $(OBJS:devices/devices.o=)That has the effect of removing the offending (i.e. non-compiling) sources from the required objects and hence make will never attempt to build them.
| Debugging C/C++ Projects |
top |
You have to customize your debug perspective to see all C/C++ actions. In the Debug perspective open "Window"-->"Customize perspective"-->"Other" and check the "C/C++ Debug" box. In the latest version it is checked by default. To customize your views open "Window"-->"Preferences"-->"Debug"-->"Debug Action groups" and check/uncheck the "C/C++ Debug" and "Java Debug" boxes.
The "Variables" view displays only local variables and arguments for the selected stack frame. You can use the "Add Expression (C/C++)" option to add a global variable to the "Expressions" view.
Yes; when you enter the debug window you can select GdbServer as debugger. Then the window information changes and you can enter the TCP-IP address and port of your target debug server or select the serial line.
Yes, partially. The console can be flipped into gdb mode (see the "Show Debugger Console" button in the debugger view which does this) and you can type in commands at that point. Doing this can possibly de-synchronize the IDE with gdb, so you should be careful to what extent you drive the debugger using this interface.
Yes, you can turn on tracing for the debug plugin and it will show you all of the information about what commands are being sent to gdb. To run with tracing:
I use some classes in standard c++ library and I'd like to view the source of it in debugging mode, just like viewing the source of my own cpp files when I stepped into some method. I've tried to add the path of gcc source (extracted from gcc tar ball) into the "Additional Source Locations" of the Source Tab in the debugging configuration for project. Could anybody tell me how to configure CDT to do this?
Check:
- if your library contains the debug information,
- if the library symbols are loaded when you try to step into a library
function (use the Shared Libraries view or set the "Load shared library
symbols automatically" options of the launch configuration),
If your library is built in a different location you should use the
"Associate with" option of the "Add Directory Source Location" dialog.
If you can get this to work, please let the cdt-dev mailing list know!
A breakpoint in DLL can be set if the symbol information of DLL is loaded in gdb. On Windows this happens when DLL is loaded. The CDT uses the "stop-on-solib-events" command of gdb to catch the moment when DLL is loaded and tries to plant the breakpoints that belong the project or the reference projects. This all is transparent for user. As far as I know (but I am not 100% sure) this option ("stop-on-solib-events") is not supported by gdb on Windows. What you can do is to stop after your DLL is loaded and then set a breakpoint in it.
The GDB debugger interface in CDT requires version 5.2.1 or later of gdb. Your version of gdb is older than this, you will need to upgrade to use gdb and CDT together.
Problem is that all the files including exe are not getting proper icon (All icons are text editor icons). Also when we try to debug the exe is not listed in the dialog so that we can select the exe from the list.
This is usually caused by having the wrong binary parser selected. Change the binary parser (from the properties on the project).
Resume failed.
Reason:
Exceptions occurred attempting to resume.
Details: Target request failed: Target is not responding (timed out)
Your version of gdb (2003-09-02-cvs cygwin-special?) had problems with "data-list-changed-registers". Disabling the updating the Registers view option (Windows->Preferences->Debug->Registers view) and unchecking the "Auto-Refresh by default" option will take care of the problem.
There is currently no integration with the dbx debugger.
There is currently no integration with the Visual Studio debugger. However, there has been some work on debugging native win32 applications using windows debuggin api's. This is not currently working, but anybody who wants to help build this is encouraged to let the CDT development community know.
If you have multiple files with the same name in your project, check off the "Search for duplicate source files" option on the "Source" tab of the launch configuration.
| Miscellaneous Troubleshooting |
top |
You should try starting Eclipse using the -vmargs -Xmx512m parameter
after the -vm argument. This will increase the Java heap size to 512MB. E.g.
./eclipse <other eclipse arguments> -vm ~/jdk/bin/java -vmargs -Xmx512m
To see more on the command line arguments of eclipse, see Running Eclipse section of the "Workbench User Guide"
There was a bug in the old version of c++filt that did not flush its output when it finishes (this same problem happens with addr2line). CDT is waiting for the answer from c++filt. You need get a new version of c++filt to fix the problem.
Unable to instantiate editor: org.eclipse.cdt.ui.editor.CEDitor. org.eclipse.core.runtime.CoreException: Plug-in org.eclipse.cdt.ui was unable to load class org.eclipse.cdt.internal.ui.editor.CEditor.
This happens when you use a mismatching eclipse and CDT builds.
| Working ON the CDT |
top |
This document describes the process of building, running and debugging the CDT within Eclipse. We will try to keep this document up-to-date with the behavior of the latest builds.
Two methods: use eclipse SDK, and link to CVS repository.
SDK
After installing the CDT-SDK, you can import CDT projects like this:
File --> import --> External Plug-ins and Fragments
select "Extract source archives and create source folders in projects"
and in the next step, you can select the projects of CDT.
CVS Repository
To build the CDT inside Eclipse you will need a build of eclipse from the Eclipse Download Page. Once you have Eclipse properly installed, the CDT CVS Repository can be accessed and the CDT plugins checked-out and built. Note: The exact steps may vary depending on what Eclipse build you use.
| Host: | dev.eclipse.org |
| Repository Path: | /home/tools |
| User: | anonymous |
| Password: | you can leave this blank |
| Connection Type: | pserver |
| Use Default Port: | selected |
| Validate Connection on Finish: | selected |
The self-hosting instructions explain how to use eclipse to develop eclipse.
Connection type: pserver
User name: anonymous
Password: <leave empty>
Host name: dev.eclipse.org
Repository path: /home/eclipse
NOTE: When you are connected as anonymous you will have read rights to the repository, but you will not be able to commit any code.
Change any file you want. When you save it, it will be built.
After successfully building the CDT inside Eclipse, one typically wants to run an instance of Eclipse with the freshly built plugins (perhaps after making some changes to the source code). This is very easy to do in the PDE. Here are the steps:
While using the Eclipse SDK to develop your plug-in, you found a bug in CDT. You submitted a bug report, but need the fix now. You've debugged the problem, and there is a simple fix. So you figured out how to use eclipse to develop eclipse and have written a fix for the bug you found. Now you want to release the fix to the eclipse community. How do you do this?
First, create a patch. You can create a patch by using the Team patch creation facility.
Now you can submit the patch to the appropriate component developer mailing list. Be sure to include information about what your patch fixes. The committers for the component will evaluate your patch to see if it fixes the bug and is acceptable. If your patch is accepted, it will be released by the component team into the repository.
Anyway that you see fit! Actually, if anybody has suggestions for this answer, please send them to the cdt-dev mailing list.
The following steps can be used to create JavaDocs for any CDT project.
The result will be a complete JavaDoc hierarchy of all the public APIs for the selected plugin.
Its little easy to develop a new error parser for ur BuildTool. Create an Extension for org.eclipse.cdt.core.ErrorParser
<extension id="NewErrorParser" name="New Error Parser" point="org.eclipse.cdt.core.ErrorParser"> <errorparser class="com.xxx.ErrorParser.NewErrorParser"> </errorparser> </extension>
have a look at the source code for (CDT GNU C/C++ Error Parser) GCCErrorParser.java . Then write a new class NewErrorParser.
The ELF parser only recognizes a fixed set of architectures. If it is not recognized as a valid type then it is recognized as "none".
E.g. To create an "AVR" aware debugger, create a plugin with the following extension:
<plugin> <extension point="org.eclipse.cdt.debug.core.CDebugger"> <debugger platform="native" name="AVR GDB Debugger" modes="run,attach" cpu="none,avr" class="org.eclipse.cdt.debug.mi.core.GDBServerDebugger" id="org.eclipse.cdt.debug.mi.core.GDBServerCDebugger"> </debugger> </extension> </plugin>The "cpu="none,avr"" part is of course the magical stuff...
To use the parser, all you need to do is put cdtparser.jar in your class path and code away. As an example, here is how the CDT Core Model instantiates and uses an IParser to build its model.
IProject currentProject = null;
boolean hasCppNature = true;
String code = ""; //$NON-NLS-1$
// get the current project
if (translationUnit != null && translationUnit.getCProject() != null) {
currentProject = translationUnit.getCProject().getProject();
}
// check the project's nature
if( currentProject != null )
{
hasCppNature = CoreModel.hasCCNature(currentProject);
}
// get the code to parse
try{
code = translationUnit.getBuffer().getContents();
} catch (CModelException e) {
}
// use quick or structural parse mode
ParserMode mode = quickParseMode ? ParserMode.QUICK_PARSE : ParserMode.STRUCTURAL_PARSE;
if(quickParseMode)
quickParseCallback = ParserFactory.createQuickParseCallback();
else
quickParseCallback = ParserFactory.createStructuralParseCallback();
// pick the language
ParserLanguage language = hasCppNature ? ParserLanguage.CPP : ParserLanguage.C;
// create the parser
IParser parser = null;
try
{
IScannerInfo scanInfo = new ScannerInfo();
IScannerInfoProvider provider = CCorePlugin.getDefault().getScannerInfoProvider(currentProject);
if (provider != null){
IScannerInfo buildScanInfo = provider.getScannerInformation(currentProject);
if (buildScanInfo != null){
scanInfo = new ScannerInfo(buildScanInfo.getDefinedSymbols(), buildScanInfo.getIncludePaths());
}
}
parser = ParserFactory.createParser(
ParserFactory.createScanner(
new StringReader( code ),
(translationUnit.getUnderlyingResource() != null ?
translationUnit.getUnderlyingResource().getLocation().toOSString() :
""), //$NON-NLS-1$
scanInfo,
mode,
language,
quickParseCallback,
quickParseMode ? new NullLogService() : ParserUtil.getScannerLogService(), null)
,quickParseCallback,
mode,
language,
ParserUtil.getParserLogService() );
}
catch( ParserFactoryError pfe )
{
throw new ParserException( CCorePlugin.getResourceString("CModelBuilder.Parser_Construction_Failure")); //$NON-NLS-1$
}
// call parse
hasNoErrors = parser.parse();
if( (!hasNoErrors) && throwExceptionOnError )
throw new ParserException(CCorePlugin.getResourceString("CModelBuilder.Parse_Failure")); //$NON-NLS-1$
return quickParseCallback.getCompilationUnit();
Here's a quick description of the ParserFactory interface methods you require:
/** * @param scanner tokenizer to retrieve C/C++ tokens * @param callback the callback that reports results to the client * @param mode the parser mode you wish to use * @param language C or C++ * @param log a log utility to output errors * @return * @throws ParserFactoryError - erroneous input provided */ public static IParser createParser( IScanner scanner, ISourceElementRequestor callback, ParserMode mode, ParserLanguage language, IParserLogService log ) throws ParserFactoryError; /** * @param input the java.io.Reader that reads the source-code input you want parsed * @param fileName the absolute path of the file you are parsing (necessary for determining location of local inclusions) * @param config represents the include-paths and preprocessor definitions you wish to initialize the scanner with * @param mode the parser mode you wish to use * @param language C or C++ * @param requestor the callback that reports results to the client * @param log a log utility to output errors * @param workingCopies a java.util.List of IWorkingCopy buffers if you wish for include files to use CDT Working Copies rather than saved files * @return * @throws ParserFactoryError - erroneous input provided */ public static IScanner createScanner( Reader input, String fileName, IScannerInfo config, ParserMode mode, ParserLanguage language, ISourceElementRequestor requestor, IParserLogService log, List workingCopies ) throws ParserFactoryError;For other information you can perhaps attach to the CVS repository @ dev.eclipse.org in order to see the rest of the code. The repository path is /home/tools and you can attach anonymously to get the source.
This is an endless list, but here are a few examples:
In addition to submitting fixes, how else can I contribute to the CDT Project?
One initially thinks of submitting patches and enhancing components as the best way to contribute. However, there are many other valuable ways to get involved and help.