Skip to main content

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

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



Back to the top