[
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
|
An alternative to the dropins folder is the links mechanism. Basically,
you create a file in {workspace}/links that points Eclipse to a directory
where it should load features and plugins from. I am not aware of any
problems with that mechanism.
http://www.ibm.com/developerworks/opensource/library/os-ecfeat/#N100B9
John
At 09:35 AM 7/26/2010, Marc Khouzam wrote:
Content-Language: en-US
Content-Type: multipart/alternative;
boundary="_000_F7CE05678329534C957159168FA70DEC5716B5E061EUSAACMS0703e_"
I tried the dropins folder myself and it
didn't work for me either.
I spoke to our release guy and he said it is safer to avoid that
solution all together...
Marc
- From: cdt-dev-bounces@xxxxxxxxxxx
[
mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Tim Black
- Sent: Friday, July 23, 2010 4:26 PM
- To: CDT General developers list.
- Subject: Re: [cdt-dev] best practices for managing a custom
eclipse/CDT build in a C++ development organization
- Now using a fresh Helios SDK + CDT 7.0.0, I switched all CDT projects
to Version v201006141710, i.e. the identical buildstamp as CDT 7.0.0
Final, and built them.
- Downloaded
patch from May 25, 2010 and applied. There were some "unmatched
hunks" and the patch dialog came up, but I just told it to apply all
changes and rebuilt CDT.
- * In the first test, I ran org.eclipse.cdt.ui as an Eclipse
Application. As before, the patch behavior is there and all is well and
good. (But, per the point of this thread, I want to share this change
with my teammates, so I need to export something...)
- * In the next test, I exported org.eclipse.cdt.dsf.gdb and
org.eclipse.cdt.dsf.gdb.ui using the same version and default buildstamp
qualifier into a directory. Copied the .jars into dropins/ and started
eclipse. Same failure as before - eclipse doesn't recognize the new
plugin versions, and the new behavior is not there.
- * Repeated previous test, but rebuilt plugins with a new version in
the plugin.xml file - I bumped the service part of the version number, so
I now have org.eclipse.cdt.dsf.gdb 3.0.1.qualifier and
org.eclipse.cdt.dsf.gdb.ui 2.1.1.qualifier. Same failed result.
- * Repeated previous test, but instead bumped the minor part of the
version number, so I now have org.eclipse.cdt.dsf.gdb 3.1.0.qualifier and
org.eclipse.cdt.dsf.gdb.ui 2.2.0.qualifier. Same failed result.
- * Repeated last three tests but copied .jars into
dropins/eclipse/plugins/ instead of dropins/. Same failed
result.
- * Next I tried exporting my 2 modified plugins with bumped minor
version into the running eclipse host. Upon restart, Eclipse shows the
new versions, and the patch behavior is there. All is well and good!
- * I then reverted the version to only bump the service number,
thinking this more appropriate for the minor change I made, so I now have
org.eclipse.cdt.dsf.gdb 3.0.1.qualifier and org.eclipse.cdt.dsf.gdb.ui
2.1.1.qualifier. When I try to export this into running eclipse instance,
I get this install error:
- -------------------------------------------------------
- Operation details
- Your original request has been modified.
-
"org.eclipse.cdt.dsf.gdb Install Patch" is already installed,
so an update will be performed instead.
-
"org.eclipse.cdt.dsf.gdb.ui Install Patch" is already
installed, so an update will be performed instead.
- Cannot complete the install because one or more
required items could not be found.
- Software currently
installed: C/C++ Development Tools SDK 7.0.0.201006141710
(org.eclipse.cdt.sdk.feature.group 7.0.0.201006141710)
- Missing requirement:
org.eclipse.cdt.dsf.gdb Install Patch 1.0.0.201007231254
(org.eclipse.cdt.dsf.gdb.patch 1.0.0.201007231254) requires
'org.eclipse.cdt.dsf.gdb.ui [2.2.0.201007231242]' but it could not be
found
- Cannot satisfy
dependency:
-
From: C/C++ Development Tools 7.0.0.201006141710
(org.eclipse.cdt.feature.group 7.0.0.201006141710)
-
To: org.eclipse.cdt.gnu.dsf.feature.group [2.1.0.201006141710]
- Cannot satisfy
dependency:
-
From: C/C++ DSF GDB Debugger Integration 2.1.0.201006141710
(org.eclipse.cdt.gnu.dsf.feature.group 2.1.0.201006141710)
-
To: org.eclipse.cdt.dsf.gdb [3.0.0.201006141710]
- Cannot satisfy
dependency:
-
From: C/C++ Development Tools SDK 7.0.0.201006141710
(org.eclipse.cdt.sdk.feature.group 7.0.0.201006141710)
-
To: org.eclipse.cdt.feature.group [7.0.0.201006141710]
- --------------------------------------------------------
- Questions/Discussion/Summary:
- * Any idea why I cannot export plugin into running host a second
time? The only change I made was to decrease the minor version and
increase the service version.
- * Either dropins/ doesn't work as expected, or I'm not properly
changing the plugin version. Is there something else you have to do to
change a plugin version number other than change the plugin.xml and
rebuild? The resulting .jar filenames do reflect my changes but they
don't seem to be getting loaded when I start eclipse...
- * Well, I did sort of get it working in a way that is
"sharable", but I have to share my entire eclipse installation,
which seems kind of coarse. When I get time, I'll try to take the
"Feature Export" approach that Marc and Chuck recommended.
- * My newbie summary is that customizing an Eclipse installation is
fraught with peril, but I have found the reality is that it is very, very
necessary. Being able to view an STL container when debugging is a good
example of how something seemingly very basic can take a long time to get
integrated into official releases of an open source debugger and IDE.
There are many examples of feature that my team needs in an IDE/debugger
that don't seem to be getting into the main releases. (Another example is
the 'refresh after build' problem, which was addressed and fixed over a
year ago but frustratingly still did not get into CDT 7.0 for some
reason.). So it has been a worthwhile excercise to understand how to
apply patches and manage dependencies in CDT and Eclipse.
- T
- On Fri, Jul 23, 2010 at 11:22 AM, Tim Black
<timblaktu@xxxxxxxxx>
wrote:
- 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