Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "Getting started with CDT development"
(→Eclipse Setup) |
m |
||
Line 90: | Line 90: | ||
Building a working cdt distribution is very difficult, but if you want just patch up your local installation you can export plugin(s) to which source patch is applied using Export->Plugins, export as archive and use your eclipse installation as destination. Make sure after this you have 2 version of the same plugin (one from installation and one new) in the plugins directory and version qualifier of your new plugin is higher. | Building a working cdt distribution is very difficult, but if you want just patch up your local installation you can export plugin(s) to which source patch is applied using Export->Plugins, export as archive and use your eclipse installation as destination. Make sure after this you have 2 version of the same plugin (one from installation and one new) in the plugins directory and version qualifier of your new plugin is higher. | ||
+ | |||
+ | [[Category:CDT]] |
Revision as of 19:13, 23 November 2012
Contents
Eclipse SDK
The very first thing you'll need to do to work on the CDT sources is install an Eclipse SDK (officially known as the Eclipse Project). The SDK contains the Eclipse platform plus other features that developers typically need to develop plug-ins, e.g., JDT and PDE. Which version of the SDK you need depends on which version of CDT you're building. To build the master branch of CDT today (October 17, 2012), you need Eclipse 3.8 or 4.2. To build an earlier version of CDT, you'll probably want to use an earlier version of Eclipse SDK. Visit the CDT downloads page to see which version of Eclipse/SDK matches a particular CDT version.
One thing to keep in mind is that as development enters the new year, the CDT team typically starts making use of new API in the platform. The platform releases new API first via milestone releases. If someone in the CDT development team commits code to the master branch that uses that new API, all CDT developers (working on the master branch) are required to use the latest Eclipse SDK milestone from that point on. Typically such decisions/changes are discussed on the CDT dev list, so check there when in doubt. Alternatively, just use the latest platform milestone for building the master branch of CDT.
Eclipse Setup
- Eclipse Classic 3.8 or 4.2 http://www.eclipse.org/downloads
- Install a separate copy of CDT 8.1 to establish an API baseline in the Preferences. See CDT/policy#Using_API_Tooling
- Install EGit (you can get it from the Juno update site). See docs http://wiki.eclipse.org/EGit/User_Guide
- Install PDE/API Tools Environment Descriptions from update site http://download.eclipse.org/eclipse/updates/3.8 (see Bug 361660)
Setting up the Sources
For detailed information on how to setup git, and check out source of CDT as a committer, see CDT/git. Otherwise, follow the non-committer setup instructions below.
Clone the Repo
From the Git perspective, select clone repo action
- Cut & Paste following url in the first page of wizard for cloning: git://git.eclipse.org/gitroot/cdt/org.eclipse.cdt.git
- It will ask you what branches to import. If you only care about head select master, if you want to work with other branches select a corresponding branch, for example cdt_8_0.
- Press Next. As location where files are stored select a folder inside your workspaces, for example workspace/cdt-git
- Press Finish (skip Gerrit page)
- This should take about 3-5 minutes
From the repo, select Import Projects...
- Select all the projects or individual. Project filter does not seems to work. It maybe easier select all, then close projects you don't need
Here's a list of projects you could start with:
- org.eclipse.cdt.codan.checkers
- org.eclipse.cdt.codan.checkers.ui
- org.eclipse.cdt.codan.core
- org.eclipse.cdt.codan.core.cxx
- org.eclipse.cdt.codan.internal.ui.cxx
- org.eclipse.cdt.codan.ui
- org.eclipse.cdt.codan.ui.cfgview
- org.eclipse.cdt.codan.ui.cxx
- org.eclipse.cdt.core
- org.eclipse.cdt.core.linux (Platform specific, change accordingly)
- org.eclipse.cdt.core.linux.x86_64 (Platform specific, change accordingly, if pressent)
- org.eclipse.cdt.debug.core
- org.eclipse.cdt.debug.mi.core
- org.eclipse.cdt.debug.mi.ui
- org.eclipse.cdt.debug.ui
- org.eclipse.cdt.dsf
- org.eclipse.cdt.dsf.gdb
- org.eclipse.cdt.dsf.gdb.ui
- org.eclipse.cdt.dsf.ui
- org.eclipse.cdt.gdb
- org.eclipse.cdt.gdb.ui
- org.eclipse.cdt.launch
- org.eclipse.cdt.make.core
- org.eclipse.cdt.make.ui
- org.eclipse.cdt.managedbuilder.core
- org.eclipse.cdt.managedbuilder.gnu.ui
- org.eclipse.cdt.managedbuilder.ui
- org.eclipse.cdt.ui
If you want to run tests, add the corresponding test project, for example, org.eclipse.cdt.core.tests.
Dependencies
Some parts of CDT have additional dependencies, which are easiest to install via update sites into your own dev environment (assuming a self hosted launch):
If using lp-parsers:
- SourceForge LPG and its Java runtime, from a stable Orbit build repository found on http://download.eclipse.org/tools/orbit/downloads/
If using test plugins:
- SWTBot, from http://download.eclipse.org/technology/swtbot/helios/dev-build/update-site
- Hamcrest Library of Matchers (not "core"), Apache Jakarta Log4j, from a stable Orbit build's update site found on http://download.eclipse.org/tools/orbit/downloads/
- via cvs, from :pserver:anonymous@dev.eclipse.org:/cvsroot/eclipse, checkout org.eclipse.test.performance
If using cross component plugins:
- TM and RSE 3.3.1 Main Features, from the Target Management (RSE) project: http://download.eclipse.org/tm/updates/3.3/
Launching
After all the CDT projects have successfully built, you'll probably want to run and/or do source-level debugging of the CDT code. Open the PDE (Plug-in Development Environment) perspective: Window->Perspective->Other->"Plug in Development". There, you'll see a project with the name org.eclipse.cdt.ui, right click the org.eclipse.cdt.ui project, select "Run As"->"eclipse application". You should see a new instance of eclipse - with the latest version of eclipse CDT plugins.
Alternatively, you can create a Launcher: Go to Run - Debug Configurations... Select "Eclipse Application" and click New. Give the Debug Configuration a Name and the other defaults are OK. This appears to be a more widely used launching technique. You may also want to go to the Arguments tab and add "-console" to the list of Program arguments. This will open an OSGi console and allow you to (temporarily) insert system.out.println statements in the CDT code to sanity check your plug-in development procedure. Regardless of whether you're launching an Eclipse Application using Debug As... or Run As..., or "deploying" your modified plugin(s) by Exporting them into a target Eclipse installation, you should see your debug println statements. Until you are familiar with the CDT code base, however, using a Debug Launcher and experimenting with breakpoints is probably the best way to get a warm fuzzy feeling if you have doubts about modifications you are making.
Note: On Mac OS X, you might need an additional argument in the launch configuration, see SWT FAQ
Submitting and Applying Patches
If you wish to contribute your changes to CDT see these instructions.
In order to apply a patch, right click the relevant project, and select Team->Apply Patch...
Keep in mind that each patch is a list of "before" and "after" text changes to files. These are highly version-specific. If you are trying to apply an old patch to newer code, or vice versa, you will encounter problems in the Apply Patch Wizard.
Creating a runtime patch
Building a working cdt distribution is very difficult, but if you want just patch up your local installation you can export plugin(s) to which source patch is applied using Export->Plugins, export as archive and use your eclipse installation as destination. Make sure after this you have 2 version of the same plugin (one from installation and one new) in the plugins directory and version qualifier of your new plugin is higher.