| Re: [cdt-dev] best practices for managing a custom eclipse/CDT build in a C++ development organization |
Von: Tim Black <timblaktu@xxxxxxxxx>
Gesendet: 23.07.2010 02:38:44
An: "CDT General developers list." <cdt-dev@xxxxxxxxxxx>
Betreff: Re: [cdt-dev] best practices for managing a custom eclipse/CDT build in a C++ development organization
When I switch all CDT plugins in my workspace to Tag CDT_7_0_0, revert my modified plugins to CDT_7_0_0 base, and attempt to apply the patch for Bug 302121, I get:
"The patch you are applying has segments that did not match. Are you sure you want to apply it?"
I didn't get this when I patched a CDT HEAD base, so I'm guessing the best approach now is to go back to using CDT HEAD, and installing a more recent CDT build instead of the 7.0 release, as Marc suggested.
So I installed the latest Nightly Build 7.0.1, reverted the CDT plugins in my workspace to CDT HEAD, applied the patch and built them again. The Eclipse Installation Details shows the same version numbers for the plugins of interest as I was seeing when using the Helios+CDT7.0 release (org.eclipse.cdt.dsf.gdb is 3.0.0 and org.eclipse.cdt.dsf.gdb.ui is 2.1.0).
Now when I export patched plugins into a folder and copy into dropins/ in a separate install of Helios+CDT7.0.1, the result is that Eclipse Installation Details still shows the old versions of the plugins (org.eclipse.cdt.dsf.gdb is 3.0.0 and org.eclipse.cdt.dsf.gdb.ui is 2.1.0), but I get some partial expected behavior (pretty print works but opening up a vector in Variables list doesn't work properly) I repeated the test copying the patched plugins into dropins/plugins and then dropins/eclipse/plugins, and got the same result.
In summary, I got the exact same failures trying to export 2 patched CDT plugins build from HEAD into a Helios + CDT 7.0.1 nightly build installation as I did into a Helios + CDT 7.0 installation. In both cases, I tried exporting the patched plugins into dropins, dropins/plugins, dropins/eclipse/plugins all with same result (doesn't pick up new plugin versions and behavior is wrong). I also tried it exporting into a running eclipse instance, and although using this method it recognizes the new plugin versions, launching encounters errors. (unhandled exception when executing Sequence org.eclipse.cdt.dsf.gdb.launching.ServicesLaunchSequence@1343bd5, step #7... see my previous post in this thread for details.)
I then tried to export all CDT plugins in my workspace (from HEAD)into the running eclipse instance, but I kept getting errors because I'm not selecting the right set of CDT plugins to export. I omitted tests/testing/platformsIDontNeed, but keep getting "can't find this or that" errors. Please let me know if there is a known set that I should export.
The only thing that has worked is to "Run As" "Eclipse Application" on org.eclipse.cdt.ui. Using this method, the behavior supplied by the patch is correct (pretty printing is correct and STL containers can be opened in Variables list to view elements in list).
I suppose the CDT nightly build 7.0.1 I'm using in my eclipse installation is not compatible with the CDT plugins in my workspace which came from HEAD. seems unlikely to me bc 7.0.1 was built just 6 days ago.
If anyone has a clue what is wrong, let me know.
Thanks,
T
On Thu, Jul 22, 2010 at 3:50 PM, Tim Black <timblaktu@xxxxxxxxx> wrote:
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.
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?
I will try the dropins/eclipse/plugins suggestion...
T
On Thu, Jul 22, 2010 at 3:04 PM, Marc Khouzam <marc.khouzam@xxxxxxxxxxxx> wrote:
You should not change the plugins directory. You should
> 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)
just use the dropins directory instead.
Same comment.
> > 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..
I thought that would work.
> > 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)
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] 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> 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> 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>
> > wrote:
> >>
> >>
> >> On 22 July 2010 10:21, Beth Tibbitts
> <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
> >> 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
| WEB.DE DSL ab 19,99 Euro/Monat. Bis zu 150,- Euro Startguthaben und 50,- Euro Geldprämie inklusive! https://freundschaftswerbung.web.de |
_______________________________________________ cdt-dev mailing list cdt-dev@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/cdt-dev ___________________________________________________________ WEB.DE DSL ab 19,99 Euro/Monat. Bis zu 150,- Euro Startguthaben und 50,- Euro Geldprämie inklusive! https://freundschaftswerbung.web.de