Bug 65358 – dev-util/eclipse-cdt-2.0-r2 failed

• Status: RESOLVED WONTFIX
• Product: Gentoo Linux

[Description Carsten Lohrke (RETIRED) 2004-09-25 15:17:15 UTC]

BUILD FAILED
/var/tmp/portage/eclipse-cdt-2.0-r2/work/eclipse-cdt-2.0/build.xml:59: Basedir /var/tmp/portage/eclipse-cdt-2.0-r2/work/eclipse-cdt-2.0/results/eclipse-copy/plugins/org.eclipse.pde.build_3.0.0/scripts does not exist

Total time: 4 seconds

[Comment 1 Bertrand Jacquin 2004-09-30 12:53:11 UTC]

Created attachment 40801 [details, diff]
Patch

Just fix a bug in an xml file
add epatch ${FILESDIR}/diff.build.xml as the end of src_unpack block in ebuild
Maybe a portage member can make a new version

[Comment 2 Tom K 2004-10-04 16:40:29 UTC]

Thanks - this worked for me. Someone should update the ebuilds in portage...

[Comment 3 Raphael Slinckx 2004-10-12 09:59:09 UTC]

The patch worked for me too using eclipse 3.0.1

[Comment 4 Andy Daniels 2004-10-28 13:13:46 UTC]

Created attachment 42799 [details]
Patch

Not everyone has an install of 3.0.1, this patch should allow the fix, but not
affect those that run 3.0.0.

[Comment 5 Andy Daniels 2004-11-03 10:59:23 UTC]

I have added a patch to bug #63905 that solves the version dependancy of eclipse-cdt more universaly (it should also be able to compile against eclipse-3.1* also).  Please test the patch posted there as the two are related.

Cheers,
Andy-

[Comment 6 Karl Trygve Kalleberg (RETIRED) 2004-11-05 17:47:36 UTC]

Nice shot, but doesn't this do the opposite it what's sensible?

If the user has both 3.1.x and 3.0.x installed, and you compile the plugin
against 3.0.x, the plugin can be loaded at runtime in both 3.0.x and 3.1.x.

If you compile it against 3.1.x, it cannot be loaded in 3.0.x, even though
the source originally allowed that.

The next revision of the eclipse-ext eclass will install all from-source plugins
in /usr/lib/eclipse-extension-<SLOT>, so that they can be shared between
SLOTs too.

I.e., since 3.1 is binary-compatible with 3.0, it will look into both 
/usr/lib/eclipse-extensions-3 and
/usr/lib/eclipse-extensions-3.1
for its plugins, whereas 3.0 will only look in
/usr/lib/eclipse-extensions-3

Given the best_version trick, the user may do:
1) Install eclipse-sdk-3.0.1
2) Install eclipse-cdt-2.0-r2
Use 3.0 for his production environment
3) Install eclipse-sdk-3.1_pre3 to play around with it
4) We release eclipse-cdt-2.0-r3
5) User upgrades to eclipse-cdt-2.0-r3
only to find that it no longer works with his 3.0 production environment!

I suggest we rather opt for compiling against the oldest supported eclipse-sdk
on the system, as it then follows the binary compatibility system for eclipse
as closely as possible then.

(If the user only has eclipse-sdk-3.1 installed when the extension actually
supports 3.0, it will not make sense to pull in 3.0 just as a compile-time
dependency, of course:)

[Comment 7 Jan Smout 2004-11-19 11:38:36 UTC]

I've discovered another problem in the eclipse-cdt ebuild. The complete story can be followed in the forums at http://forums.gentoo.org/viewtopic.php?t=234957&highlight=

Summary:
The eclipse-sdk ebuild has a USE flag 'gtk', which has the obvious effect of using the GTK+ widget set when its used. Otherwise, standard Motif is used.
However, the eclipse-cdt ebuild doesn't have this USE flag but assumes the presence of the GTK+ library in its build. The result is that the build of eclipse-cdt fails as described in the post (that is, after applying one of the solutions to overcome the eclipse-3.0.0 dependency).

I would suggest to add the gtk USE flag to eclipse-cdt as well, but I don't know whether this is possible for cdt. That's something I leave to the ebuild developers/maintainers.

[Comment 8 Karl Trygve Kalleberg (RETIRED) 2004-11-24 08:31:41 UTC]

*** Bug 36472 has been marked as a duplicate of this bug. ***

[Comment 9 Zac Witte 2004-12-05 19:47:59 UTC]

both patches gave me errors, but I just changed 3.0.0 to 3.0.1 in /var/tmp/portage/eclipse-cdt-2.0-r2/work/eclipse-cdt-2.0/build.xml and it worked for me.

Why hasn't a fix been made to the official ebuild yet?

[Comment 10 Karl Trygve Kalleberg (RETIRED) 2004-12-16 04:04:04 UTC]

Nerdboy kindly requested that dev-tools take over all eclipse stuff

[Comment 11 Andrew Cowie 2005-02-02 22:39:34 UTC]

I'm glad that dev-tools wants control of this, but does anyone in dev-tools actually *use* eclipse and can they resolve this bug?

As it stands right now, eclipse-cdt still requires 3.0.0, and that's silly given that, as described, a user will most certainly have 3.0.1 installed.

While I grant that some of the solutions proposed here are not 100% ideal, they are at least forward progress and would cover a great number of cases (3.0.1/GTK users) - certainly until eclipse 3.1 goes live, anyway.

AfC

[Comment 12 Karl Trygve Kalleberg (RETIRED) 2005-02-12 17:34:29 UTC]

I'd like to remind the audience that the CDT has an update site and thus is available through the Eclipse Update Manager.

That being said, I'm still fiddling with this in spare moments, but it's rather messy. 

[Comment 13 Kai Schlüter 2005-05-20 02:50:11 UTC]

Created attachment 59356 [details]
Adjusted ebuild

I just added the build.xml patch and changed a = to a >= to allow newer Eclipse
versions to be used. Works on my box like a charm.

[Comment 14 Josh Nichols (RETIRED) 2006-07-20 12:22:09 UTC]

eclipse-cdt is package.mask'd, pending removal.

[Comment 15 Josh Nichols (RETIRED) 2006-07-20 12:23:03 UTC]

FOrgot to actually resolve...