On Tue, 21 Feb 2006 10:45:58 -0500
Joshua Nichols <firstname.lastname@example.org> 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 . 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.
email@example.com mailing list