1 |
On Tue, 21 Feb 2006 10:45:58 -0500 |
2 |
Joshua Nichols <nichoj@g.o> wrote: |
3 |
|
4 |
> For JDK-like environment, redhat has done much work on this already. It |
5 |
> is, surprisingly enough, called java-gcj-compat. Take a look at the |
6 |
> jpackage rpm for it [1]. You can find other sites for java-gcj-compat, |
7 |
> but the jpackage rpm seems to have the highest version I was able to find. |
8 |
|
9 |
I did test java-gcj-compat already. It is of no use other than |
10 |
java/javac links to gij/gcj. If that is what you want I may add that |
11 |
symlinks to the ebuild. Besides that I work on OOo2. There you |
12 |
need a JDK-like environment with gij/gcj and not java/javac |
13 |
executables. As far as I looked at applications they look for gij/gcj |
14 |
instead of java/javac then. So I do not see any use of that |
15 |
java-gcj-compat package. It produces more work and things get |
16 |
even more ugly. |
17 |
|
18 |
As for ecj applications have --with-ecj switch or alike. |
19 |
I will have a look on gcj/ecj issue for applications after |
20 |
ant-core-1.6.5 merged with ecj. |
21 |
|
22 |
> This shouldn't be much of a problem. The build.xml is pretty trivial, so |
23 |
> you should be able to replicate it using javac and jar. |
24 |
|
25 |
True. Hacked up a build.sh for ecj native version already. |
26 |
|
27 |
> There really isn't much 'integration' involved per se. You mostly just |
28 |
> have to create an env file that contains information about JAVA_HOME, |
29 |
> PATH, etc. Take a look at existing jdk/jre packages. |
30 |
|
31 |
That would be great. I will see. |
32 |
|
33 |
> I'm not fond of the name gcj-jdk. The ebuild Andrew made was just for |
34 |
> gcj itself, without the Java compatibility stuff, iirc. -jdk suggests |
35 |
> that it provides a usable JDK, which it doesn't as it was. |
36 |
|
37 |
Well, I would just say gcj is a bit different than usual JDKs. |
38 |
I am fine to rename it to dev-java/gcj. It is a gcc front-end. |
39 |
No matter what. So you are right for naming. |
40 |
But it provides a usable JDK in its way and usable by application |
41 |
already in Portage. (see above) |
42 |
|
43 |
> Speaking of which, I think the added compatibility layer (for javac, |
44 |
> java, etc) should be a separate package. I'm not sure if this was your |
45 |
> intention or not. Either way, it would make sense, since you would most |
46 |
> likely be able to use the same layer for different versions of gcj. |
47 |
|
48 |
At the moment I do not see a reason to slot it. You just want the |
49 |
latest version of gcj 4.1 because of enhancements and fixes. |
50 |
GCJ 4.0 is missing too many features. |
51 |
|
52 |
The reason why I want to push on gcj is because with gcj 4.1 |
53 |
and ecj as bytecompiler you get Azureus build and running. |
54 |
|
55 |
|
56 |
Regards, |
57 |
Hanno |
58 |
-- |
59 |
gentoo-java@g.o mailing list |