My team is using the Helios/CDT7.0 release and I have recently found a need to patch CDT (bug 302121 to provide viewing of STL containers, see earlier thread on "displaying as array" behavior). I would now like to share this patched version of Eclipse with my team
and am looking for suggestions for best practices in doing so. To date,
we have always used the official releases, 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.
Presumably this patch only changed a few cdt plugins, and I think these
are org.eclipse.cdt.dsf.gdb and org.eclipse.cdt.dsf.gdb.ui. I have
experimented with exporting the affected plugins and copying them to a
real eclipse installation (overwriting the previous org.eclipse.cdt.dsf.gdb and org.eclipse.cdt.dsf.gdb.ui plugins), but for whatever reason, when I run that eclipse installation, the following wrong things happen: (a) when I do a Help->About Eclipse->Installation Details->Plug-ins, it still lists the old version of the plug-ins. I guess the patched ones I built have a new .jar filename but the same internal versioning info. I've run into this before and I think was told that it's not a problem.
(b) when I view the launch configuration I was using in my previous test (same workspace), the available settings look different. E.g. there is no indication at the bottom which "Launcher Create Process" is active, and on the Debug tab, it doesn't have the new CDT 7.0 settings for "reverse debugging", etc..
(c) it is obviously using my new patched plugins, bc when debugging I see some print-out of vector details in the variable-view pane, however, the behavior is different than before. It prints out details, but it doesn't allow viewing elements in the variable tree like it did when I tested the patched plugins by "Run As" "eclipse Application".
Any ideas what I've done wrong? Could I have missed a plugin that was affected by the patch?
For multiple reasons, however, I am more interested in learning how to
manage a complete in-house eclipse build, including eclipse platform and
(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?
It looked to me like the thing to do is "Export" "Eclipse Product".
But when I went to define a Product Configuration, it was not clear how
to define the settings in the .product file. Is this the right path for someone in my shoes to take, or are there other, simpler, ways to share an eclipse build? E.g. after I get a custom-built eclipse installation working the way I want, can I simply share my eclipse installation folder with my teammates? (My understanding is that no preferences are stored in the eclipse installation folder, but in the eclipse workspace folder (and project files)).