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

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:

       > 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] 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


Back to the top