Re: [cdt-dev] best practices for managing a custom eclipse/CDT build in

[Olexiy Buyanskyy <olexiyb@xxxxxxxxx>]

Hi,

We had the same goals. As result we do export of all sources into our
CVS vendor branch.
Apply patches and build custom version of CDT.
CVS allows to export new set of changes and merge to vendor branch.
So we always on track with changes in CDT.

You can look in my wiki page.

https://olexiyb.dyndns.org/mediawiki/index.php/BuildSCM#Eclipse_CDT

All our developers install and upgrade from internal web site.

--
Olexiy


On Wed, Jul 21, 2010 at 7:16 PM, Tim Black <timblaktu@xxxxxxxxx> wrote:
> 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
>
>