Skip to main content
Jump to: navigation, search

Difference between revisions of "Getting started with CDT development"

Line 30: Line 30:
  
 
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.<br>  
 
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.<br>  
 +
 +
Note: On Mac OS X, you might need an additional argument in the launch configuration, see [http://www.eclipse.org/swt/faq.php#cocoa32launch SWT FAQ]
  
 
;Submitting and Applying Patches
 
;Submitting and Applying Patches

Revision as of 10:08, 3 July 2010

Getting started with CDT development for the latest CVS head

Preparing workspace

First you need to get the correct eclipse version which you will use to develop plugins. To build the CDT source code from CVS HEAD requires Eclipse 3.6 (Helios), so browse downloads page and grab this version. It should contain both the JDT and PDE plugins that would allow you to develop plugins for eclipse.

  • For example, on http://download.eclipse.org/eclipse/downloads/, under the "Eclipse 3.6 and 3.5.x Stream Stable Builds" heading (grey bar), select Eclipse 3.6M6 (or a later one if available) - and on the next page, select Eclipse SDK - and download it.

Unzip or untar this archive, and launch eclipse.

Now let's download the CDT source code.

  • Click on the following file and download it to your machine: http://www.eclipse.org/cdt/psf/cdt-main.psf
  • If you are not a committer, open the psf in a text editor and do a search-n-replace: "extssh" ==> "pserver"
  • Go to: File > Import > Team > Team Project Set and select the psf
  • You will be prompted for a username and password. Non-committers should enter "anonymous" for username, and an email address for the password.
  • The above Project Set points to HEAD bc it is most commonly used by CDT development team. If you create any new useful Project Sets, e.g. for specific Branches or Versions of CDT, add them to the wiki here.

The fairly long process of checking out all the sources from CVS will begin.

After you checkout, JDT will build all the projects for you. If you have any error markers, you might be missing some plugins or have a version mismatch between CDT and Eclipse SDK.

You may not want to work with CVS HEAD, because you happen to be using the latest Eclipse release package or maybe you are troubleshooting a problem and need to confirm/deny its existence in various versions. In this case, you need to match your Eclipse SDK version with the desired CDT version. The CDT downloads page has info about determining the right pairing.

Even if you need to get an older version of CDT, it is still recommended to start with CVS HEAD using the .psf file as mentioned above. Once you know what version of CDT you need for your version of Eclipse, then you can select the CDT plugins in your workspace, right click, select Team - "Switch to Another Branch or Version". Choose "Select the tag from the following list" and click the Refresh Tags button. Once the refreshing process is complete, you may browse for and select the version you need. "Versions" contains snapshots in time which are static, and "Branches" contains a dynamically updated branch from HEAD at some point in the past. Usually you want the latter, so you can easily pick up any newly committed functionality and bug fixes.

Launching

Now, move back to 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.

In case you've applied a patch, and you wish to revert back to the latest HEAD branch - right click the project, then "Replace With->Latest From HEAD", answer Yes to the warning message, and the patch is gone.

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.

Back to the top