Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Difference between revisions of "Getting started with CDT development"

m (Getting started with CDT development for the latest CVS head)
m (Getting started with CDT development for the latest CVS head)
Line 3: Line 3:
 
;Preparing workspace<br>
 
;Preparing workspace<br>
  
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 corresponding version of Eclipse (such as 3.7 corresponds CDT 8.0 being in development on HEAD as of April 2011), so browse [http://download.eclipse.org/eclipse/downloads downloads page] and grab latest 3.X version. It should contain both the JDT and PDE plugins that would allow you to develop plugins for eclipse.  
+
In June 2011, CDT officially transitioned off CVS and onto Git.
 +
 
 +
Committers will want to access the repository via ssh
 +
 
 +
  ssh://git.eclipse.org/gitroot/cdt/org.eclipse.cdt.git
 +
 
 +
Everyone else will use either of the following URLs
 +
 
 +
  git://git.eclipse.org/gitroot/cdt/org.eclipse.cdt.git
 +
  http://git.eclipse.org/gitroot/cdt/org.eclipse.cdt.git
 +
 
 +
Doug Schaefer has posted numerous screencasts on using eGit
 +
 
 +
Using Git GUI with Eclipse Part I - Setting up the workspace
 +
 
 +
  [http://www.youtube.com/watch?v=DcM1xOiaidk&feature=related http://www.youtube.com/watch?v=DcM1xOiaidk&amp;feature=related]
 +
 
 +
Using Git GUI with Eclipse Part II - Pushing changes to the server
 +
 
 +
  http://www.youtube.com/watch?v=1OrPJClD92s&amp;feature=related
 +
 
 +
Setting up SSH authorized keys in Eclipse
 +
 
 +
http://www.youtube.com/watch?v=WU9xYP_NScQ
 +
 
 +
Creating and Applying Patches to CDT git repo
 +
 
 +
  http://www.youtube.com/watch?v=Lhwi3z2DyzQ&amp;feature=related
 +
 
 +
CDT Pushing Changes to Maste
 +
 
 +
  http://www.youtube.com/watch?v=I5uq6dWdi0w&amp;feature=related
 +
 
 +
First you need to get the correct eclipse version which you will use to develop plugins. To build the CDT source code from the master branch requires a corresponding version of Eclipse Project (i.e., the "SDK") E.g., working on CDT 8.0 requires having Eclipse 3.7 or higher. The Eclipse Project releases are available here: http://download.eclipse.org/eclipse/downloads
 +
 
 +
, so browse [http://download.eclipse.org/eclipse/downloads downloads page] and grab latest 3.X 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.
 
*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.
Line 31: Line 66:
 
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]
+
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 15:56, 25 June 2011

Getting started with CDT development for the latest CVS head

Preparing workspace

In June 2011, CDT officially transitioned off CVS and onto Git.

Committers will want to access the repository via ssh

  ssh://git.eclipse.org/gitroot/cdt/org.eclipse.cdt.git

Everyone else will use either of the following URLs

  git://git.eclipse.org/gitroot/cdt/org.eclipse.cdt.git
  http://git.eclipse.org/gitroot/cdt/org.eclipse.cdt.git

Doug Schaefer has posted numerous screencasts on using eGit

Using Git GUI with Eclipse Part I - Setting up the workspace

  http://www.youtube.com/watch?v=DcM1xOiaidk&feature=related

Using Git GUI with Eclipse Part II - Pushing changes to the server

  http://www.youtube.com/watch?v=1OrPJClD92s&feature=related

Setting up SSH authorized keys in Eclipse

http://www.youtube.com/watch?v=WU9xYP_NScQ

Creating and Applying Patches to CDT git repo

  http://www.youtube.com/watch?v=Lhwi3z2DyzQ&feature=related

CDT Pushing Changes to Maste

  http://www.youtube.com/watch?v=I5uq6dWdi0w&feature=related

First you need to get the correct eclipse version which you will use to develop plugins. To build the CDT source code from the master branch requires a corresponding version of Eclipse Project (i.e., the "SDK") E.g., working on CDT 8.0 requires having Eclipse 3.7 or higher. The Eclipse Project releases are available here: http://download.eclipse.org/eclipse/downloads

, so browse downloads page and grab latest 3.X 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 link, download and save this file 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