On Tue, 21 Feb 2006 10:45:58 -0500
Joshua Nichols <nichoj@g.o> wrote:

> For JDK-like environment, redhat has done much work on this already. It 
> is, surprisingly enough, called java-gcj-compat. Take a look at the 
> jpackage rpm  for it [1]. You can find other sites for java-gcj-compat, 
> but the jpackage rpm seems to have the highest version I was able to find.

I did test java-gcj-compat already. It is of no use other than
java/javac links to gij/gcj. If that is what you want I may add that
symlinks to the ebuild. Besides that I work on OOo2. There you
need a JDK-like environment with gij/gcj and not java/javac
executables. As far as I looked at applications they look for gij/gcj
instead of java/javac then. So I do not see any use of that
java-gcj-compat package. It produces more work and things get
even more ugly.

As for ecj applications have --with-ecj switch or alike.
I will have a look on gcj/ecj issue for applications after
ant-core-1.6.5 merged with ecj.

> This shouldn't be much of a problem. The build.xml is pretty trivial, so 
> you should be able to replicate it using javac and jar.

True. Hacked up a build.sh for ecj native version already.

> There really isn't much 'integration' involved per se. You mostly just 
> have to create an env file that contains information about JAVA_HOME, 
> PATH, etc. Take a look at existing jdk/jre packages.

That would be great. I will see.

> I'm not fond of the name gcj-jdk. The ebuild Andrew made was just for 
> gcj itself, without the Java compatibility stuff, iirc. -jdk suggests 
> that it provides a usable JDK, which it doesn't as it was.

Well, I would just say gcj is a bit different than usual JDKs.
I am fine to rename it to dev-java/gcj. It is a gcc front-end.
No matter what. So you are right for naming.
But it provides a usable JDK in its way and usable by application
already in Portage. (see above)

> Speaking of which, I think the added compatibility layer (for javac, 
> java, etc) should be a separate package. I'm not sure if this was your 
> intention or not. Either way, it would make sense, since you would most 
> likely be able to use the same layer for different versions of gcj.

At the moment I do not see a reason to slot it. You just want the
latest version of gcj 4.1 because of enhancements and fixes.
GCJ 4.0 is missing too many features.

The reason why I want to push on gcj is because with gcj 4.1
and ecj as bytecompiler you get Azureus build and running.


Regards,
Hanno
-- 
gentoo-java@g.o mailing list