[
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
|
Dropins are a kludge. There's been a lot of reports about them not
working any more, or at least being unreliable. Using p2 properly is
the way to go.
On Mon, Jul 26, 2010 at 10:35 AM, Marc Khouzam
<marc.khouzam@xxxxxxxxxxxx> wrote:
> I tried the dropins folder myself and it didn't work for me either.
> I spoke to our release guy and he said it is safer to avoid that
> solution all together...
>
> Marc
>
>
>
> ________________________________
> From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On
> Behalf Of Tim Black
> Sent: Friday, July 23, 2010 4:26 PM
> To: CDT General developers list.
> Subject: Re: [cdt-dev] best practices for managing a custom eclipse/CDT
> build in a C++ development organization
>
> Now using a fresh Helios SDK + CDT 7.0.0, I switched all CDT projects to
> Version v201006141710, i.e. the identical buildstamp as CDT 7.0.0 Final, and
> built them.
> Downloaded patch from May 25, 2010 and applied. There were some "unmatched
> hunks" and the patch dialog came up, but I just told it to apply all changes
> and rebuilt CDT.
>
> * In the first test, I ran org.eclipse.cdt.ui as an Eclipse Application. As
> before, the patch behavior is there and all is well and good. (But, per the
> point of this thread, I want to share this change with my teammates, so I
> need to export something...)
>
> * In the next test, I exported org.eclipse.cdt.dsf.gdb and
> org.eclipse.cdt.dsf.gdb.ui using the same version and default buildstamp
> qualifier into a directory. Copied the .jars into dropins/ and started
> eclipse. Same failure as before - eclipse doesn't recognize the new plugin
> versions, and the new behavior is not there.
> * Repeated previous test, but rebuilt plugins with a new version in the
> plugin.xml file - I bumped the service part of the version number, so I now
> have org.eclipse.cdt.dsf.gdb 3.0.1.qualifier and org.eclipse.cdt.dsf.gdb.ui
> 2.1.1.qualifier. Same failed result.
> * Repeated previous test, but instead bumped the minor part of the version
> number, so I now have org.eclipse.cdt.dsf.gdb 3.1.0.qualifier and
> org.eclipse.cdt.dsf.gdb.ui 2.2.0.qualifier. Same failed result.
> * Repeated last three tests but copied .jars into dropins/eclipse/plugins/
> instead of dropins/. Same failed result.
>
> * Next I tried exporting my 2 modified plugins with bumped minor version
> into the running eclipse host. Upon restart, Eclipse shows the new versions,
> and the patch behavior is there. All is well and good!
> * I then reverted the version to only bump the service number, thinking this
> more appropriate for the minor change I made, so I now have
> org.eclipse.cdt.dsf.gdb 3.0.1.qualifier and org.eclipse.cdt.dsf.gdb.ui
> 2.1.1.qualifier. When I try to export this into running eclipse instance, I
> get this install error:
> -------------------------------------------------------
> Operation details
> Your original request has been modified.
> "org.eclipse.cdt.dsf.gdb Install Patch" is already installed, so an
> update will be performed instead.
> "org.eclipse.cdt.dsf.gdb.ui Install Patch" is already installed, so
> an update will be performed instead.
> Cannot complete the install because one or more required items could not
> be found.
> Software currently installed: C/C++ Development Tools SDK
> 7.0.0.201006141710 (org.eclipse.cdt.sdk.feature.group 7.0.0.201006141710)
> Missing requirement: org.eclipse.cdt.dsf.gdb Install Patch
> 1.0.0.201007231254 (org.eclipse.cdt.dsf.gdb.patch 1.0.0.201007231254)
> requires 'org.eclipse.cdt.dsf.gdb.ui [2.2.0.201007231242]' but it could not
> be found
> Cannot satisfy dependency:
> From: C/C++ Development Tools 7.0.0.201006141710
> (org.eclipse.cdt.feature.group 7.0.0.201006141710)
> To: org.eclipse.cdt.gnu.dsf.feature.group [2.1.0.201006141710]
> Cannot satisfy dependency:
> From: C/C++ DSF GDB Debugger Integration 2.1.0.201006141710
> (org.eclipse.cdt.gnu.dsf.feature.group 2.1.0.201006141710)
> To: org.eclipse.cdt.dsf.gdb [3.0.0.201006141710]
> Cannot satisfy dependency:
> From: C/C++ Development Tools SDK 7.0.0.201006141710
> (org.eclipse.cdt.sdk.feature.group 7.0.0.201006141710)
> To: org.eclipse.cdt.feature.group [7.0.0.201006141710]
> --------------------------------------------------------
>
> Questions/Discussion/Summary:
> * Any idea why I cannot export plugin into running host a second time? The
> only change I made was to decrease the minor version and increase the
> service version.
> * Either dropins/ doesn't work as expected, or I'm not properly changing the
> plugin version. Is there something else you have to do to change a plugin
> version number other than change the plugin.xml and rebuild? The resulting
> .jar filenames do reflect my changes but they don't seem to be getting
> loaded when I start eclipse...
> * Well, I did sort of get it working in a way that is "sharable", but I have
> to share my entire eclipse installation, which seems kind of coarse. When I
> get time, I'll try to take the "Feature Export" approach that Marc and Chuck
> recommended.
> * My newbie summary is that customizing an Eclipse installation is fraught
> with peril, but I have found the reality is that it is very, very necessary.
> Being able to view an STL container when debugging is a good example of how
> something seemingly very basic can take a long time to get integrated into
> official releases of an open source debugger and IDE. There are many
> examples of feature that my team needs in an IDE/debugger that don't seem to
> be getting into the main releases. (Another example is the 'refresh after
> build' problem, which was addressed and fixed over a year ago but
> frustratingly still did not get into CDT 7.0 for some reason.). So it has
> been a worthwhile excercise to understand how to apply patches and manage
> dependencies in CDT and Eclipse.
>
> T
>
>
> On Fri, Jul 23, 2010 at 11:22 AM, Tim Black <timblaktu@xxxxxxxxx> wrote:
>>
>> Trying to install CDT 8.0.0 in Helios to get exported patched cdt.dsf.gdb
>> plugins (from HEAD) to work:
>>
>> I first made a copy of my eclipse Helios+CDT7.0.1 installation and tried
>> upgrading to CDT 8.0.0 nightly build. This failed bc it recognized multiple
>> versions of org.eclipse.cdt.managedbuilder.core (said only one of 8.0.0,
>> 7.0.1, 7.0.0 can be installed at once).
>>
>> So I started over with the standard eclipse-SDK-3.6 release and tried
>> installing CDT 8.0.0 nightly on top of that. Same error. (can't install
>> 7.0.0 and 8.0.0 at once)
>>
>> Are these errors happening because CDT 8.0 has to be used with eclipse 3.7
>> instead of Helios? The CDT 8.0 nightly build page says it runs against
>> matching milestone build of Eclipse 3.7 only. But I wasn't able to find an
>> Eclipse 3.7 (SDK) download anywhere, although there are "3.6 stream builds"
>> with similar dates. Am I interpreting this correctly?
>>
>> If that's the case, this means one cannot use the latest patch for Bug
>> 302121 unless they are using eclipse 3.7. Right?
>>
>> If so, I guess I'm probably better off abandoning HEAD and trying to get
>> this working using Helios + CDT 7.0 + apply older patch to June 14th dsf.gdb
>> plugins...
>>
>> T
>>
>> On Fri, Jul 23, 2010 at 10:29 AM, Tim Black <timblaktu@xxxxxxxxx> wrote:
>>>
>>> Thanks, Marc and everyone, for your insight and suggestions. Working with
>>> and (especially) modifying Eclipse and CDT can be overwhelming, but it is a
>>> pleasure to receive such rapid and thorough feedback from the development
>>> team. :-) As in any complex and highly generic framework, there appear to be
>>> several ways to solve a problem.
>>>
>>> I aspire to cultivate a process such as Marc outlined most recently, so
>>> my organization can pick up features (sorry, I know this word is overloaded
>>> here...) as they are added to the 7.0 branch over time without having to
>>> deal with the instability of HEAD. And btw, ftr it seems this process is
>>> very close to the one described earlier by Chuck Wilson. Except that Chuck
>>> uses the 7.0 tag instead. And he mentioned creating a Feature Project (which
>>> I don't know anything about yet...)
>>>
>>> Choosing a starting point for a custom, patched CDT build seems to depend
>>> on what patches or modifications you need to apply. Not being much of a java
>>> programmer myself, I mostly rely on (leech off?) the patches created by
>>> others. So for me, I must choose the starting point that requires the least
>>> amount of manual modifications to apply patches of interest. And not
>>> understanding the architecture of CDT, I find it difficult to determine
>>> dependencies between patches and CDT code - afaik the date of the patch is
>>> all I have to go on. And because the changes within a patch reflect changes
>>> to files from several different dates, there's a lot of guesswork at
>>> determining what CVS location to start from. (for me, at least)
>>>
>>> Is it true that most patches are written to apply to/work with HEAD at
>>> the time, with the intent being that they will get merged into HEAD? If so,
>>> this motivates me to stay on the bleeding edge, but I have had problems
>>> building from HEAD before (for days at a time), so I'd have to be prepared
>>> for that..
>>>
>>> Thanks again. I'll report back when I have more results.
>>>
>>> T
>>>
>>> On Fri, Jul 23, 2010 at 6:07 AM, Marc Khouzam <marc.khouzam@xxxxxxxxxxxx>
>>> wrote:
>>>>
>>>> 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
>>>> >
>>>> _______________________________________________
>>>> cdt-dev mailing list
>>>> 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
>
>
