Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[cdt-dev] Re: best practices for managing a custom eclipse/CDT build in a C++ development organization 
On 7/21/2010 7:16 PM, Tim Black wrote:

My team is using the Helios/CDT7.0 release and I have recently found a
need to patch CDT

...

and now I'm looking at maintaining an internal eclipse and/or
CDT build that I would selectively update to HEAD and/or merge in
patches as need arises, and share the resulting eclipse build with the
team.

My goal is to keep the process as simple as possible for my teammates,
so all they have to do is copy some files. I don't want them to have to
checkout CDT code and apply patches themselves.

...
As it happens, I spent most of yesterday figuring out how to do this. However, I used a "feature patch" rather than a complete build of eclipse/CDT. By exporting that feature patch to a (p2) repository, my team can use the Install New Software facility to install the patches, on top of a normal Eclipse/CDT product. 


For multiple reasons, however, I am more interested in learning how to
manage a complete in-house eclipse build, including eclipse platform and
CDT:
(a) For me to share my exported plugins, I must assume that my team is
all using the exact eclipse platform and CDT installation I used when I
patched CDT.
(b) In the future we will come across more bugs and feature-problems
that will require patches. Maybe it's easier to just do a complete build?
I dunno if that would be easier or not; if you just need to patch a few bits in CDT, I'd expect that feature patches are easier. If you need to update lots of stuff in Eclipse itself, and CDT...well. 

So here's what I did:

1) create a workspace and import the cdt project set
   http://www.eclipse.org/cdt/psf/cdt-main.psf

(Obviously you need the PDE and the Eclipse SDK installed)
2) Switched all of those projects to the Helios 7.0.0 tag (CTR_7_0_0) -- not HEAD nor the CDT_7_0 branch. That way, I'm guaranteed that all the other plugins from my workspace will be identical to the ones I have installed -- except for my patches. 

3) Patched all the affected plugins that needed modification
4) In the *same* workspace, created (a number of) new Feature Patch projects. You have to create multiple ones, because each Feature Patch is specific to an individual feature in the CDT. So, in my case I had modifications to the following four plugins 
	org.eclipse.cdt.debug.core
	org.eclipse.cdt.debug.ui
	org.eclipse.cdt.managedbuilder.core
	org.eclipse.cdt.managedbuilder.gnu.ui
This means I had to create two different feature patches, because the first three plugins are part of one feature, but the last plugin is part of another: 

   com.my-company.my-activity.eclipse.cdt.platform.patch
      which included the updated plugins for the
      org.eclipse.cdt.platform feature, that is:
        org.eclipse.cdt.debug.core
        org.eclipse.cdt.debug.ui
        org.eclipse.cdt.managedbuilder.core

   com.my-company.my-activity.eclipse.cdt.gnu.build.patch
      which included the updated plugins for the
      org.eclipse.cdt.gnu.build feature, that is:
        org.eclipse.cdt.managedbuilder.gnu.ui
Note that you need to have all the information above at hand, before starting the New Feature Patch Project wizard.
5) Now, this is important. You have to set the version of the included plugins to a specific value; you don't want to rely on the .qualifier buildstamp. So, I modified the plugin.xml of all four plugins above to generate a literal version of 7.0.0.v201007211600 (note the "v"). And, the feature.xml manifests for the Feature Patch projects specify exactly that version number.
Naturally I didn't pick that version number until after I was finished developing and testing /in situ/ using the Debug Launch Configurations.
I did, however, continue to use the .qualifier version number on the Feature Patch projects /themselves/.
6) Then, using the Export Deployable Features wizard, I exported both Feature Patch projects to a directory that I planned to use as the update site. On the 'Options' tab, make sure that 'package as individual jar archives' is checked, and that 'generate repository metadata' is checked.
Do NOT check export source. If you do, then your repository will have two identically named and identically versioned 'Feature Patch' entities for each project, and you have no way to tell which one is the actual patch and which is the source bundle -- until after you install it.
Note that each time you export the Feature Patch, the plugins included with each will be rebuilt. That's why you need a fixed value for the (patched) plugin version number, and can't use the .qualifier; otherwise, it'll change every time you export the Feature Patch, but it has to match the value encoded in the feature.xml.
7) Finally, in the 'Install New Software' dialog, 'Add' a 'Local' repository matching the location to which you exported. You should see the Feature Patch objects (make sure 'Group Items by category' is NOT checked, or uncategorized items -- like these -- will be hidden).
If your team can 'see' that repository location, they can use step 7 as well, without having to build anything themselves.
The down side to this approach is that the patch is tied specifically to version 7.0.0 of the CDT. There are some websites that purport to describe how to modify the Ant build scripts to automatically indicate some range of compatible 'base' plugin versions to replace, but manually mucking about with Ant scripts is WAY outside my comfort zone. 


Hope that helps.

--
Chuck

Back to the top