[
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
|
Sounds like a good discussion to have on p2-dev. I do know Red Hat has
similar requirements in their distro,
On Wed, Aug 4, 2010 at 6:10 PM, James Blackburn
<jamesblackburn@xxxxxxxxx> wrote:
> On 4 Aug 2010, at 22:34, Doug Schaefer <cdtdoug@xxxxxxxxx> wrote:
>
>> We've seen issues with links and dropins. Using p2 is really the only
>> safe way to install plug-ins.
>
> In fact I've asked again and again for guidance on managing multiple
> user installs -- how do I keep peoples eclipses up to date? How do I
> minimise disk usage on expensive filers? And most importantly: how do
> I ensure when I update a feature in some shared central p2 repository
> that I don't break one of dozens of eclipses that are running
> concurrently and have been for weeks...
>
> I haven't found any answers to the above - there's no documentation on
> this use case and afaics shared installs has fallen by the wayside.
>
> With links and dropins, I can install each version of a feature in a
> separate ditectory, chmod -R -r the directory, and can then guarantee
> that I won't accidentally break the feature at some point in the
> future.
>
> I've had my fair share of trouble with p2, and I guess the problems I
> have stem from lack of understanding. From a practical point of view,
> if a team can build their project with cdt 7 + features today, they
> should be able to build the same tagged source with that version of
> the toolchain next year. If we cant explicitly manage versions, then
> the above quickly falls apart. Big shared p2 repositories don't offer
> that flexibility.
>
> We spin a couple cdt snapshot releases a week here. With official
> internal releases coming once a month or so. The same is true of the
> rest of the toolchain - compilers, debuggers, and simulators. As cdt
> is an Integral part of our toolchain it needs to be easy for users to
> both choose versions, and guarantee that those versions will continue
> to work in the future. At the moment dropins is the only way to
> version orthogonal independent sets of features per user/team.
>
> Perhaps the worlds easier if each user has a standalone IDE on her desktop :)
>
> Cheers
> James
>
>>
>> On Wed, Aug 4, 2010 at 5:03 PM, John Cortell <rat042@xxxxxxxxxxxxx> wrote:
>>> I meant {eclipse}/links
>>>
>>> At 04:00 PM 8/4/2010, John Cortell wrote:
>>>
>>> An alternative to the dropins folder is the links mechanism. Basically, you
>>> create a file in {workspace}/links that points Eclipse to a directory where
>>> it should load features and plugins from. I am not aware of any problems
>>> with that mechanism.
>>>
>>> http://www.ibm.com/developerworks/opensource/library/os-ecfeat/#N100B9
>>>
>>> John
>>>
>>> At 09:35 AM 7/26/2010, Marc Khouzam wrote:
>>>
>>> Content-Language: en-US
>>> Content-Type: multipart/alternative;
>>>
>>> boundary="_000_F7CE05678329534C957159168FA70DEC5716B5E061EUSAACMS0703e_"
>>>
>>> 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
>>>
>>> _______________________________________________
>>> 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
> _______________________________________________
> cdt-dev mailing list
> cdt-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/cdt-dev
>
