Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cdt-dev] best practices for managing a custom eclipse/CDT build in a C++ development organization

>It looked to me like the thing to do is "Export" "Eclipse Product".
No, that is for building an RCP product.
You want to export deployable plug-ins and fragments.
You could build a set of the plug-ins that you have changed, and your users could apply those to the downloaded CDT installation.
You just want the version numbers to be greater than the default CDT's so they are recognized.
On the options tab of the export dialog, the "qualifier replacement" can use today's date and thus it's "greater than" the date that the base CDT was built.
I think what you build this way, your users could copy into the eclipse/dropins folder to install.
Alternatively you could build an update site.

...Beth

Beth Tibbitts
Eclipse Parallel Tools Platform http://eclipse.org/ptp
IBM STG Communications Protocols and Tools
Mailing Address: IBM Corp., Coldstream Research Campus, 745 West New Circle Road, Lexington, KY 40511

Inactive hide details for Tim Black ---07/21/2010 07:16:15 PM---My team is using the Helios/CDT7.0 release and I have recently Tim Black ---07/21/2010 07:16:15 PM---My team is using the Helios/CDT7.0 release and I have recently found a need to patch CDT (bug


From:

Tim Black <timblaktu@xxxxxxxxx>

To:

"CDT General developers list." <cdt-dev@xxxxxxxxxxx>

Date:

07/21/2010 07:16 PM

Subject:

[cdt-dev] best practices for managing a custom eclipse/CDT build in a C++ development organization

Sent by:

cdt-dev-bounces@xxxxxxxxxxx




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 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?

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)).

Thanks for any advice you can offer,
Tim
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev


GIF image

GIF image


Back to the top