Bugzilla Bug 97347

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 an attachment (id=62179) [details]
dev-util/eclipse-sdk ebuild (works at least on amd64)

Created an attachment (id=62180) [details]
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 an attachment (id=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 an attachment (id=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 an attachment (id=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] 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.