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

I jumped in a little late on the thread but I thought I'd tell
you what we've been doing internally for a similar situation, where
we've needed to release a patched CDT to our users.  It's been working
pretty well for us.

We take the 7_0 branch since it is less 'in flux' than HEAD,
we patch it with the features we need extra, and we do an
entire CDT build. Here are the steps:

1- Install an Helios release of the platform (no CDT)
2- Check out the list of plugins below from the branch cdt_7_0
3- Change the version of every feature.xml file checkedout
   (this is a bit of a mystery to me)
4- Patch the code with whatever changes you need.  Those changes
   _must_ be compatible with cdt_7_0, so you need to pick your
   patches carefully, or adapt them.
5- Once everything is compiled and tested, you should export the
   CDT features.  This must be done on the same type of machine
   as were your users will run it (e.g., Linux64, Windows, etc)
6- right-click on any plugin and choose Export...
7- Select "Deployable Features" under "Plugin development"
8- You only need to check org.eclipse.cdt.
9- Choose the Destination to be a zip file of your choice
10- The resulting zip file can be used to install you own
    version of CDT on top of Helios.

Plugins I checkout to build CDT:
org.eclipse.cdt/
org.eclipse.cdt.core/
org.eclipse.cdt.core.aix/
org.eclipse.cdt.core.linux/
org.eclipse.cdt.core.linux.ia64/
org.eclipse.cdt.core.linux.ppc/
org.eclipse.cdt.core.linux.x86/
org.eclipse.cdt.core.linux.x86_64/
org.eclipse.cdt.core.macosx/
org.eclipse.cdt.core.qnx/
org.eclipse.cdt.core.solaris/
org.eclipse.cdt.core.win32/
org.eclipse.cdt.debug.core/
org.eclipse.cdt.debug.mi.core/
org.eclipse.cdt.debug.mi.ui/
org.eclipse.cdt.debug.ui/
org.eclipse.cdt.doc.isv/
org.eclipse.cdt.doc.user/
org.eclipse.cdt.dsf/
org.eclipse.cdt.dsf.gdb/
org.eclipse.cdt.dsf.gdb.ui/
org.eclipse.cdt.dsf.ui/
org.eclipse.cdt-feature/
org.eclipse.cdt.gdb/
org.eclipse.cdt.gdb-feature/
org.eclipse.cdt.gdb.ui/
org.eclipse.cdt.gnu.build-feature/
org.eclipse.cdt.gnu.debug-feature/
org.eclipse.cdt.gnu.dsf-feature/
org.eclipse.cdt.launch/
org.eclipse.cdt.make.core/
org.eclipse.cdt.make.ui/
org.eclipse.cdt.managedbuilder.core/
org.eclipse.cdt.managedbuilder.gnu.ui/
org.eclipse.cdt.managedbuilder.ui/
org.eclipse.cdt.p2/
org.eclipse.cdt.p2-feature/
org.eclipse.cdt.p2.generator/
org.eclipse.cdt.platform-feature/
org.eclipse.cdt.sdk/
org.eclipse.cdt.sdk-feature/
org.eclipse.cdt.ui/

Below are optional plugins if you want other features.
You would need to also select the checkbox for their
feature when exporting since they are not part of
the main CDT feature.

GDB harware debugging:
org.eclipse.cdt.debug.gdbjtag/
org.eclipse.cdt.debug.gdbjtag.core/
org.eclipse.cdt.debug.gdbjtag-feature/
org.eclipse.cdt.debug.gdbjtag.ui/

Enhanced memory feature for debugging:
org.eclipse.cdt.debug.ui.memory-feature/
org.eclipse.cdt.debug.ui.memory.memorybrowser/
org.eclipse.cdt.debug.ui.memory.search/
org.eclipse.cdt.debug.ui.memory.traditional/
org.eclipse.cdt.debug.ui.memory.transport/

And there is also CODAN, EDC and probably
other features that I'm not very familiar with.

Marc


> -----Original Message-----
> From: cdt-dev-bounces@xxxxxxxxxxx
> [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Marc Khouzam
> Sent: Friday, July 23, 2010 7:04 AM
> To: CDT General developers list.
> Subject: RE: [cdt-dev] best practices for managing a custom
> eclipse/CDT build in a C++ development organization
>
>
> ________________________________
> From: cdt-dev-bounces@xxxxxxxxxxx
> [cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Tim Black
> [timblaktu@xxxxxxxxx]
> Sent: July 22, 2010 6:50 PM
> To: CDT General developers list.
> Subject: Re: [cdt-dev] best practices for managing a custom
> eclipse/CDT build in a C++ development organization
>
> About reusing version numbers, I haven't manually or
> intentionally changed any version numbers when exporting
> plugins, except for the qualifier, which is automatically
> updated on export. The version bump I assume occurred between
> CDT7.0 and HEAD.
>
>
>
> Each time you want to use the dropins folder you must update
> the version of each plugin to something that the eclipse
> installation has never seen before.  I think updating the
> minor version is enough.
>
>
> Marc, I see that you're actively involved in the discussion
> for Bug 302121, which contains the patch I'm using. Would you
> happen to know what snapshot of CDT I should get to apply
> this patch? I don't understand how to determine what CVS
> tag/HEAD to use for any given patch. As I mentioned, I used
> CDT HEAD at first, because I knew the patch was very recent.
> The patch applied and built and seemed to work when I tested
> using self-hosting, so I thought HEAD was the right choice.
> Should I try rebuilding them from 7.0?
>
>
>
> For HEAD you should use the patch posted on the 16th of July.
>
> Re-building from 7.0 would be just as tricky because the code
> in the 7_0 branch has also changed since Helios and you would need
>
> to update it all anyway.  The value of using 7_0 is that is
> may be more stable than HEAD since it got less changes.  For
> a deployment
>
> that may be better.
>
>
>
> Another thing you could do is to check out
> org.eclipse.cdt.dsf.gdb and org.eclipse.cdt.dsf.gdb.ui which
> are compatible with Helios.
>
> I'm not sure what the proper way to do this is, maybe someone
> else knows.  One way you could do this is to check out based on a
>
> date, which would be June 14th.  If you check out those two
> plugins as they were on June 14th, you will be able to deploy them
>
> directly on a Helios release.
>
>
>
> If you do get the June 14th of those two plugins, you should
> patch them using the patch of bug 302121 of May 25th (notice it is
>
> marked at obsolete simply because it no longer applies to HEAD.)
>
>
>
> Marc
>
>
>
>
>
>
> I will try the dropins/eclipse/plugins suggestion...
>
> T
>
> On Thu, Jul 22, 2010 at 3:04 PM, Marc Khouzam
> <marc.khouzam@xxxxxxxxxxxx<mailto:marc.khouzam@xxxxxxxxxxxx>> wrote:
>
>        > 8. At this point I tried a few approaches:
> >       >    a. Copy the 2 patched .jar files into
> > eclipse_test1/plugins/. There are
> >       > now 2 .jars for each of the patched plugins, with
> > different versions (the
> >       > patch must have modified this) and qualifiers.
> >       >       The result running this eclipse is that Eclipse
> > Installation Details
> >       > still shows the old versions of the plugins, but I
> > get some partial expected
> >       > behavior (pretty print works but opening up a vector
> > doesn't work)
>
> You should not change the plugins directory.  You should
> just use the dropins directory instead.
>
> >       >    b. Delete the older versions of patched .jars,
> > leaving just the ones I
> >       > just built.
> >       >       The result running this eclipse is that eclipse
> > doesn't even load my
> >       > patched plugins and the dsf gdb debugging behavior
> > and ui is wrong. Probably
> >       > a version dependency problem..
>
> Same comment.
>
> >       >    c. Now using a fresh eclipse install. Copy the 2
> > patched .jar files into
> >       > eclipse_test2/dropins/. There are still the original
> > unpatched .jars in
> >       > plugins/.
> >       >       Same result as a. The result running this
> > eclipse is that Eclipse
> >       > Installation Details still shows the old versions of
> > the plugins, but I get
> >       > some partial expected behavior (pretty print works
> > but opening up a vector
> >       > doesn't work)
>
> I thought that would work.
> Try putting those new plugins in
> dropins/eclipse/plugins
>
> Note also that you cannot re-use version numbers, even
> the version is different than the original plugin.
> So, if things don't work, try exporting the plugins again
> with a version you've never used before and using the
> dropins folder.
>
> Marc
>
>
>
> > -----Original Message-----
> > From:
> cdt-dev-bounces@xxxxxxxxxxx<mailto:cdt-dev-bounces@xxxxxxxxxxx>
> >
> [mailto:cdt-dev-bounces@xxxxxxxxxxx<mailto:cdt-dev-bounces@ecl
ipse.org>] On Behalf Of Tim Black
> > Sent: Thursday, July 22, 2010 5:38 PM
> > To: CDT General developers list.
> > Subject: Re: [cdt-dev] best practices for managing a custom
> > eclipse/CDT build in a C++ development organization
> >
> > Original plugins:
> > org.eclipse.cdt.dsf.gdb_3.0.0.201006141710
> > org.eclipse.cdt.dsf.gdb.ui_2.1.0.201006141710
> >
> > New plugins:
> > org.eclipse.cdt.dsf.gdb_3.1.0.201007221231
> > org.eclipse.cdt.dsf.gdb.ui_2.2.0.201007221231
> >
> > So, the version is different as well as the qualifier. The
> > original plugins are from a standard Helios/CDT7.0 "for C/C++
> > Developers" release. The new plugins were built from CDT
> HEAD + patch.
> >
> > T
> >
> >
> > On Thu, Jul 22, 2010 at 1:12 PM, Alena Laskavaia
> > <elaskavaia.cdt@xxxxxxxxx<mailto:elaskavaia.cdt@xxxxxxxxx>> wrote:
> >
> >
> >       What is your exported plugins qualifier looks like
> > compared to original ones?
> >
> >
> >       On Thu, Jul 22, 2010 at 4:08 PM, Tim Black
> > <timblaktu@xxxxxxxxx<mailto:timblaktu@xxxxxxxxx>> wrote:
> >       > Thanks, Everyone, for your suggestions. We may
> > someday consider setting up a
> >       > single shared/multi-user eclipse installation, but
> > for my current needs,
> >       > making copies of an eclipse installation folder is
> > probably the simplest way
> >       > to achieve what I want to do. My "users" don't have
> > to know about plugins,
> >       > etc, they just copy the eclipse install dir just like
> > they do with public
> >       > releases. Now I just have to get my exported plugins
> > to work (like they did
> >       > when I did Run As -> Eclipse Application)...
> >       >
> >       > Thanks for mentioning the dropins/ folder. Didn't
> > know that existed. I tried
> >       > dropping my patched ,exported .jars into dropins/ but
> > the result is still a
> >       > failure, i.e. (a) Plug-ins tab of Eclipse
> > Installation Details still shows
> >       > the old version for those plugins, and (b) the new
> > patched behavior is not
> >       > present (like it was when I did "Run As" "Eclipse
> > Application" on
> >       > org.eclipse.cdt.ui)
> >       >
> >       > I've been through this before and still haven't
> > figured out how to "deploy
> >       > plugins". Can anyone see what I've done wrong?
> >       >
> >       > 0. Starting with the standard Helios/CDT7.0 release
> > (for C/C++ developers),
> >       > I installed Eclipse SDK using Help->Install New
> > Software. Restarted Eclipse
> >       > and switch to Plugin Dev Perspective.
> >       > 1. Got CDT HEAD using project set file import.
> >       > 2. Build all CDT plugins in workspace. (There are
> > errors but only in
> >       > org.eclipse.cdt.tests.dsf)
> >       > 3. Got and applied latest CDT patch (for viewing STL
> > containers) at
> >       > https://bugs.eclipse.org/bugs/show_bug.cgi?id=302121.
> >       > 4. Build all CDT plugins in workspace. There are no
> > more errors than before.
> >       > Good.
> >       > 5. Right click org.eclipse.cdt.ui and Run As..
> > Eclipse Application. New
> >       > plugin behavior is present (pretty print view of STL
> > containers). About
> >       > Eclipse - Eclipse Installation Details - Plug-ins
> > just shows "qualifier" for
> >       > the qualifier for versions of CDT plugins. Close the
> > "Run As" Eclipse
> >       > instance.
> >       > 6. Back in the Plugin Package Explorer, there are
> > only 2 CDT plugins with
> >       > ">" appended to their name indicating they have been
> > modified. These are
> >       > org.eclipse.cdt.dsf.gdb and
> > org.eclipse.cdt.dsf.gdb.ui. Select both, and
> >       > Export... Deployable plug-ins and fragments. Specify
> > directory but change no
> >       > other defaults. (qualifier defaults to date/time)
> >       > 7. Close Eclipse. There are now no eclipse instances
> > running. Make copies of
> >       > eclipse/ install folder called eclipse_test1/ and
> > eclipse_test2/.
> >       > 8. At this point I tried a few approaches:
> >       >    a. Copy the 2 patched .jar files into
> > eclipse_test1/plugins/. There are
> >       > now 2 .jars for each of the patched plugins, with
> > different versions (the
> >       > patch must have modified this) and qualifiers.
> >       >       The result running this eclipse is that Eclipse
> > Installation Details
> >       > still shows the old versions of the plugins, but I
> > get some partial expected
> >       > behavior (pretty print works but opening up a vector
> > doesn't work)
> >       >    b. Delete the older versions of patched .jars,
> > leaving just the ones I
> >       > just built.
> >       >       The result running this eclipse is that eclipse
> > doesn't even load my
> >       > patched plugins and the dsf gdb debugging behavior
> > and ui is wrong. Probably
> >       > a version dependency problem..
> >       >    c. Now using a fresh eclipse install. Copy the 2
> > patched .jar files into
> >       > eclipse_test2/dropins/. There are still the original
> > unpatched .jars in
> >       > plugins/.
> >       >       Same result as a. The result running this
> > eclipse is that Eclipse
> >       > Installation Details still shows the old versions of
> > the plugins, but I get
> >       > some partial expected behavior (pretty print works
> > but opening up a vector
> >       > doesn't work)
> >       >
> >       > Thanks,
> >       > T
> >       >
> >       >
> >       > On Thu, Jul 22, 2010 at 2:28 AM, James Blackburn
> > <jamesblackburn@xxxxxxxxx<mailto:jamesblackburn@xxxxxxxxx>>
> >       > wrote:
> >       >>
> >       >>
> >       >> On 22 July 2010 10:21, Beth Tibbitts
> > <tibbitts@xxxxxxxxxx<mailto:tibbitts@xxxxxxxxxx>> wrote:
> >       >>>
> >       >>> >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.
> >       >>
> >       >> Or alternatively you can install the eclipse
> > centrally and use a shared
> >       >> install. This may make sense if you *nix based and
> > your IT infrastructure
> >       >> means  that you have tools installed centrally on
> > shared NFS filers:
> >       >>
> >       >>
> > http://help.eclipse.org/help32/topic/org.eclipse.platform.doc.
> > isv/reference/misc/multi_user_installs.html
> >       >>
> >       >> Cheers,
> >       >> James
> >       >>
> >       >>
> >       >> _______________________________________________
> >       >> cdt-dev mailing list
> >       >> cdt-dev@xxxxxxxxxxx<mailto:cdt-dev@xxxxxxxxxxx>
> >       >> https://dev.eclipse.org/mailman/listinfo/cdt-dev
> >       >>
> >       >
> >       >
> >       > _______________________________________________
> >       > cdt-dev mailing list
> >       > cdt-dev@xxxxxxxxxxx<mailto:cdt-dev@xxxxxxxxxxx>
> >       > https://dev.eclipse.org/mailman/listinfo/cdt-dev
> >       >
> >       >
> >       _______________________________________________
> >       cdt-dev mailing list
> >       cdt-dev@xxxxxxxxxxx<mailto:cdt-dev@xxxxxxxxxxx>
> >       https://dev.eclipse.org/mailman/listinfo/cdt-dev
> >
> >
> >
> > _______________________________________________
> cdt-dev mailing list
> cdt-dev@xxxxxxxxxxx<mailto:cdt-dev@xxxxxxxxxxx>
> https://dev.eclipse.org/mailman/listinfo/cdt-dev
>
> _______________________________________________
> cdt-dev mailing list
> cdt-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/cdt-dev
>


Back to the top