Home | Docs | Forums | Lists | Bugs | Planet | Store | GMN | Get Gentoo!

Full Text Bug Listing

GNU Classpath 0.16 was released some days ago.

Reproducible: Always
Steps to Reproduce:

Created an attachment (id=63379) [details]
Updated ebuild

I fixed the dependencies for Classpath:
- libart_lgpl is out
- gtk+ is now >=2.4 (was >=2)
- cairo-0.5 (!)
The cairo lib is only needed if the corresponding flag is set. I already
applied the wish mentioned in bug #93552 to move cairo to media-libs (instead
of x11-libs).

Using the ebuild from bug #93552 with this one works without problems here
(x86).

0.17 out now.  Seems like mostly bug fixes to 0.16.

I'm not sure if the dependency on gdk-pixbuf is necessary. I think GNU
Classpath
can use version 2 of the gdkpixbuf library, which comes with gtk 2.4+.
Classpath
seemed to build ok with gtk's version of gdk-pixbuf anyway. I haven't done much
testing with the classpath I merged, however. 

A SPEC file (http://lists.gnu.org/archive/html/classpath/2005-03/msg00159.html)
sent to the classpath ml listed gdk-pixbuf 2.0 as a dep. That doesn't
necessarily mean the SPEC file was correct, of course. I thought I'd post this
comment to see if anyone with more knowledge could shed some light. Meanwhile,
I'll test my classpath ebuild some more.

P.S. I changed the subject to reflect that 0.17 is out. I hope no one minds.

Created an attachment (id=68395) [details]
ebuild for classpath 0.18

Since cairo is still in x11-libs I changed this again in this ebuild.

Btw: Although Classpath was only updated specifically to the API changes of
cairo 0.5.0 it still compiles and works with 1.0.0

Btw2: This ebuild does not support the new Qt4 peers. Lets look how much
integration of Qt4 in Gentoo and Classpath has happened in two months and I'll
fix that with CP's next release.

renamed.

Created an attachment (id=68400) [details]
patch for ebuild

in short. rev1.4 to rev1.5 change plus my changes.

Header cleanup
gtk -> gtk2 useflag
gcj useflag
gdk-pixbuf dep not needed -> pulls gtk1. no go.

Hi some remarks:

gcj useflag

You need at least GCJ3.4 or the build will break. I thought it would add
unnecessary overhead to the ebuild (detecting right gcj3.4, fallback to jikes on
x86 currently) and left it out. For the future Classpath (>0.18) one even needs
GCJ4.0.
Given that GCJ is not the best, not the fastest compiler and Gentoo is *not*
exploiting its native compilation feature (hint. hint.) I propose to use jikes
(and ecj) in all places.

gdk-pixbuf dep not needed

I'll ask the classpath team about this.

gcj useflag:
i added sys-devel/gcc-4.0.1 depend for gcj. ~x86 runs that compiler.
sys-devel/gcc got gcj useflag. so why not using?! senseless to me. but gentoo
devs sure know better. does not matter if it is the best or fastest. it is an
alternative to sun-jdk/blackdown-jdk which some people dislike.

gdk-pixbuf depend:
drop it because it is _gtk+-1_. pulls gtk1 stuff which is just not needed!
gnu-classpath configure checks for gdk-pixbuf-2.0 pkg-config file. no idea what
package ships gdk-pixbuf-2.0. may be gtk+-2? however, i got it without
gdk-pixbuf package.

Yep gdk-pixbuf-2.0 comes with gtk+2. So it is not needed as a dependency you
said (next classpath release will reflect this change in its README/INSTALL file).

Your GCJ addition looks good. GCJ4.0.1 is a good choice (especially for the future).

Then there is only one thing:
+		 gtk2? ( >=x11-libs/gtk+-2.4 >=media-libs/libart_lgpl-2.1 )

libart_lgpl is not needed any more.

I did not touch that part (libart_lgpl). It is from rev1.5.
You may just drop it so.

Created an attachment (id=68459) [details]
package.env for java-config classpath

foer this purpose:

$ java-config -l
...
[classpath] Free core class libraries for use with virtual machines and
compilers for the Java programming language (/usr/share/classpath/package.env)
...

$ java-config --classpath=classpath
/usr/share/classpath/glibj.zip

At least OOo2 GCJ build needs that for canvas/source/java part.

Created an attachment (id=68466) [details]
ebuild patch with discussed changes and package.env generation

No idea if 'files="${files%:}"' or 'files="${files%%:}"' is correct. Both gave
same results on tests.

gnu-classpath-0.18 was just added to the tree. I had to drop the cairo use flag
because the required cairo version is still package.masked and I can't add the
gcj use flag because of the same reason. I also feel the it is the task of the
vm/runtime environment to now where the core library is located so I did not put
the package.env installation. Choosing the compiler is something that we are
looking in the future and ecj will probably be our compiler of choice. You can
reopen this bug or make a new one for the package.env file if you really want it
to be added. But thanks for the work you all. You can find the gcj use flag in
the experimental tree but I haven't tested it.