The eclipse 3.1 final has been released. I'll attach an ebuild that works for amd64. My ebuild is quite different from the previous ebuilds because it uses the eclipse build system directly instead of trying to quess what to do. I think that after the eclipse 3.1 ebuild has been added most of the bugs against the 3.1_pre or 3.1_rc releases can be closed. Some of them can of course still be valid with this release and ebuild. Reproducible: Always Steps to Reproduce:
Created attachment 62179 [details] dev-util/eclipse-sdk ebuild (works at least on amd64)
Created attachment 62180 [details, diff] small patches to fix eclipse build system problems
*** This bug has been marked as a duplicate of 95855 ***
I don't understand why this is a duplicate. This bug is requesting an ebuild for the *final* 3.1 release, not a release candidate or milestone, and is also proposing content of a potentially high caliber for possible inclusion. IMHO, Mikko's comments seems sound: that the various buglets for milestone and release candidate releases should probably be culled and the emphasis placed upon discussing the best way of getting this important release into portage. His understanding of the platform and its build system have already been demonstrated - shouldn't this bug be considered further?
I would like to hear any success/failure reports on x86 or ppc platforms, I have not done any changes that should break them but there might still be some strangeness in the eclipse build system that can break. Also I have tried to make sure the build works on both ibm and sun (or derivative) JVM, gcj most likely won't work. Currently this has only been built on amd64 platform using sun 1.5.0_04 jdk.
I tried on ~x86 with sun 1.5.0_04 jdk and this is what happened: * To build Eclipse, at least 768MB of RAM is recommended. * Your machine has less RAM. Continuing anyway. Detected a JDK >= 1.5.0 Detected a JDK >= 1.4.2 >>> Unpacking source... >>> Unpacking eclipse-sourceBuild-srcIncluded-3.1.zip to /var/tmp/portage/eclipse-sdk-3.1/work/eclipse-sdk-3.1 * Applying eclipse-3.1.patch ... [ ok ] * Setting up virtual machine Detected a JDK >= 1.5.0 * Cleaning out prebuilt code * Patching build * Optimizing for Java 1.4 VM * Patching makefiles >>> Source unpacked. * Using bootclasspath /opt/sun-jdk-1.5.0.04/jre/lib/rt.jar:/opt/sun-jdk-1.5.0.04/jre/lib/jsse.jar * Using JVM library path /opt/sun-jdk-1.5.0.04/jre/lib/x86 !!! ERROR: dev-util/eclipse-sdk-3.1 failed. !!! Function setup-jvm-opts, Line 297, Exitcode 0 !!! Could not find libawt.so native library !!! If you need support, post the topmost build error, NOT this statu
Created attachment 62223 [details] dev-util/eclipse-sdk ebuild, x86 fixes Fixes problem with * Using JVM library path /opt/sun-jdk-1.5.0.04/jre/lib/x86 with this ebuild it should be correctly * Using JVM library path /opt/sun-jdk-1.5.0.04/jre/lib/i386
The ebuild has been confirmed to work on x86
I've problems with cairo USE flag. First emerge failed with cairo is not exists, then i emerged x11-libs/cairo-0.1.23-r1 but then it failed with cairo-xlib.h does not exists. Arch is x86, both dev-java/sun-jdk-1.5.0.03 and dev-java/blackdown-jdk-1.4.2.02 tried. Now im compiling it, will report situation; pardus ~ # USE="-gcj atk" emerge -vp eclipse-sdk These are the packages that I would merge, in order: Calculating dependencies ...done! [ebuild NS ] dev-util/eclipse-sdk-3.1 +atk -cairo -doc -gcj -gnome -jikes -mozilla -src 0 kB [1]
With USE="-gcj atk" emerge -vp eclipse-sdk eclipse-sdk has been built. [ebuild R ] dev-util/eclipse-sdk-3.1 +atk -cairo -doc -gcj -gnome -jikes -mozilla -src 0 kB [1]
(In reply to comment #4) > I don't understand why this is a duplicate. This bug is requesting an ebuild for > the *final* 3.1 release, not a release candidate or milestone Hmm, and why don't you attach the ebuild to the other bug and change summary accordingly? Why do we need a mirriad of open bugs on one thing?
*** Bug 95855 has been marked as a duplicate of this bug. ***
*** Bug 92606 has been marked as a duplicate of this bug. ***
S.Caglar Onur, which version of cairo do you have installed? I have myself compiled it against cairo-0.3.0-r2 successfully. I tried to search from eclipse/swt pages what would be the official required cairo version but the only reference I could find was swt FAQ which claims one needs cairo 0.4.0, which doesn't seem to be true. http://dev.eclipse.org/viewcvs/index.cgi/%7Echeckout%7E/platform-swt-home/faq.html#nographicslibrary If you could try compiling once more with cairo 0.3.0 to try if it works. I can then update the required version in the ebuild to match that one.
*** Bug 97420 has been marked as a duplicate of this bug. ***
Confirmed working on ~x86 and ~amd64, compiled the gtk version of eclipse using sun-jdk-1.5.0.04 and Cairo 0.3.0-r2. Additionally, I did a quick check that it compiles and works using blackdown-sdk-1.4.2.02 on ~amd64. I think this is great!
Created attachment 62275 [details] dev-util/eclipse-sdk ebuild This ebuild adds explicit cairo-0.3.0-r2 dependency. It also works around buggy ibm-jdk jawt.h header file on amd64. So far confirmed working against following JVM's: amd64: - ibm 1.4.2 - blackdown 1.4.2 - sun 1.5.0 x86: - blackdown 1.4.2
To be clear, SWT 3.1 has an advanced graphics API which uses cairo, and we tested it against cairo 0.4.0. This API is not used by Eclipse itself, so even if the libswt-gtk-cairo-3138.so file does not exist, Eclipse will still run just fine. The dependency on 0.4.0 is really cairo < 0.5.0, since 0.5.0 breaks the API and we don't have a port to that yet (it was released too late for Eclipse 3.1). So, 0.3.0 will probably work since there aren't as many changes between 0.3 and 0.4.
3.1 working great here... 1.4.2_08 Sun JDK, x86 Only issue is the menu link is placed in /usr/share/applnk instead of /usr/share/applications, though many may not care. :)
working on ~x86 with sun 1.5.0_04 jdk, too
Works on x86 with Java 1.5.0_04 ( without doc/src ). I will try the doc/src USE-flag later.
The ebuild is missing `firefox' inside the IUSE line.
Created attachment 62328 [details] dev-util/eclipse-sdk ebuild - Moves the eclipse-3.1.desktop file from /usr/share/applnk/Development to /usr/share/applications. - Adds firefox IUSE flag. - Disallowed cairo >= 0.5 in RDEPEND - Removed explicit blackdown-jdk RDEPEND (copied from earlier ebuilds) which is not needed because blackdown-jdk should provide the correct virtual/jdk - Added TODO list into the ebuild
the 'eclipse-3.1.desktop' seems to be missing... and I get LOT'S of warnings, most about private variables/functions never used. But eclipse 3.1 is working great !
(In reply to comment #14) > S.Caglar Onur, which version of cairo do you have installed? I have myself > compiled it against cairo-0.3.0-r2 successfully. x11-libs/cairo-0.3.0-r2 works also with me... [ i used 0.1.23-r1 before ]
A few comments: - I'll probably disable cairo support. Billy says it's not used by Eclipse itself, it will break in the future, and that it's experimental. We have a separate SWT build, and that will have cairo support. Objections? - I'll revert 'src' and 'doc' to 'nosrc' and 'nodoc'. Why? Because the Eclipse SDK is pretty much useless for writing Eclipse plugins without the documentation and the source code for debugging. I think it's a sane default to provide documentation and source code. It's just cumbersome for users to realize that they need to recompile this huge beast just because they forgot these two USE flags. If Portage had supported per-package use flag defaults, I'd kept 'src' and 'doc', but for now, we have to work around that.
I didn't get any script to launch eclipse, I must run it with : > java -jar /usr/lib/eclipse-3.1/startup.jar I didn't get any desktop entry neither, so I put this into the ebuild : > make_desktop_entry "java -jar /usr/lib/eclipse-${PV}/startup.jar" \ > "Eclipse ${PV}" "/usr/lib/eclipse-${PV}/icon.xpm" Development
Re: comment 24 and comment 27 - that's not a problem with the ebuild. When testing ebuilds that have not yet been accepted into the portage tree please be sure to copy files from the "files/" sub-directory into the overlay. You need to copy at least the following: * files/eclipse-3.1 (startup script) * files/eclipse.1 (manpage) * files/eclipse-3.1.desktop (desktop entry) If in doubt, please just copy the entire subdirectory in future when testing prospective ebuilds. Furthermore, attachment 62180 [details, diff] on this bug should be saved as files/eclipse-3.1.patch.
Okay, I put this one in the tree, with some modifications. I expect there to be more than a few issues popping up soon, so don't hesitate to reopen the bug with input.
