Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [cdt-dev] best practices for managing a custom eclipse/CDT build in a C++ development organization

________________________________
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@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<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



Back to the top