Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cdt-dev] Weekly builds of CDT 8.0

Have you tried the cdt-nightly builds on hudson?

On Sun, Aug 1, 2010 at 10:49 AM, Andrew Gvozdev <angvoz.dev@xxxxxxxxx> wrote:
> Can we resume weekly builds for the HEAD, i.e. CDT 8.0? Sadly, the only
> version on CDT 8.0.0 Download page is not installable.
>
> Andrew
>
> On Mon, Jul 26, 2010 at 10:53 AM, Andrew Gvozdev <angvoz.dev@xxxxxxxxx>
> wrote:
>>
>> I increased managedbuilder plugin version but neglected to correct the
>> features. Sorry for inconvenience. It's fixed now, the latest Hudson
>> build cdt-master-8.0.0-I201007260957.zip is installable.
>>
>> Andrew
>>
>> On Mon, Jul 26, 2010 at 9:04 AM, Marc Khouzam <marc.khouzam@xxxxxxxxxxxx>
>> wrote:
>>>
>>> This never made to the list for some reason.
>>> ________________________________
>>> From: Marc Khouzam
>>> Sent: Friday, July 23, 2010 3:27 PM
>>> To: 'CDT General developers list.'
>>> Subject: RE: [cdt-dev] best practices for managing a custom eclipse/CDT
>>> build in a C++ development organization
>>>
>>> I also cannot install the nightly build on 3.6.  The error message is:
>>>
>>> Cannot complete the install because of a conflicting dependency.
>>>   Software being installed: C/C++ Development Tools 7.1.0.201007121006
>>> (org.eclipse.cdt.feature.group 7.1.0.201007121006)
>>>   Only one of the following can be installed at once:
>>>     CDT Build System Core 8.0.0.201007121006
>>> (org.eclipse.cdt.managedbuilder.core 8.0.0.201007121006)
>>>     CDT Build System Core 7.0.0.201006141710
>>> (org.eclipse.cdt.managedbuilder.core 7.0.0.201006141710)
>>>   Cannot satisfy dependency:
>>>     From: C/C++ Development Tools 7.1.0.201007121006
>>> (org.eclipse.cdt.feature.group 7.1.0.201007121006)
>>>     To: org.eclipse.cdt.platform.feature.group [7.1.0.201007121006]
>>>   Cannot satisfy dependency:
>>>     From: C/C++ Development Platform 7.1.0.201007121006
>>> (org.eclipse.cdt.platform.feature.group 7.1.0.201007121006)
>>>     To: org.eclipse.cdt.managedbuilder.core [7.0.0,8.0.0)
>>>   Cannot satisfy dependency:
>>>     From: C/C++ Development Platform 7.1.0.201007121006
>>> (org.eclipse.cdt.platform.feature.group 7.1.0.201007121006)
>>>     To: org.eclipse.cdt.managedbuilder.core [8.0.0.201007121006]
>>>
>>> I've looked at the org.eclipse.cdt.platform-feature plugin's feature.xml
>>> file and I noticed that in the Dependencies
>>> tab, it asks for something "Compatible" to 7.0.0 for
>>> org.eclipse.cdt.managedbuilder.core.
>>> On the other hand (for example) org.eclipse.cdt.dsf, it asks for
>>> something "Greater or Equal" than 2.0.0
>>>
>>> Could this be the problem?
>>>
>>> Marc
>>>
>>>
>>> ________________________________
>>> From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On
>>> Behalf Of Tim Black
>>> Sent: Friday, July 23, 2010 2:23 PM
>>> To: CDT General developers list.
>>> Subject: Re: [cdt-dev] best practices for managing a custom eclipse/CDT
>>> build in a C++ development organization
>>>
>>> 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
>
>


Back to the top