| 1 |
-----BEGIN PGP SIGNED MESSAGE----- |
| 2 |
Hash: SHA1 |
| 3 |
|
| 4 |
On Tuesday 20 May 2003 12:32 pm, Chris Davies wrote: |
| 5 |
> Hi, |
| 6 |
> |
| 7 |
> Secondly, there is simply no advantage to compiling java applications on |
| 8 |
> the system in question. It is a complete waste of time. Java compiles |
| 9 |
> into machine independant bytecode. The same Java code compiled by the |
| 10 |
> same compiler on two different architectures should produce exactly the |
| 11 |
> same result. So unless you plan to offer gcj as an alternative |
| 12 |
> compilation tool, compiling from source is utter waste of the user's |
| 13 |
> time. It is dogmatic in the extreme to suggest that because we compile |
| 14 |
> programs that generate machine dependant object code on the system |
| 15 |
> itself, all programs on the system should be compiled. Compilation is a |
| 16 |
> means to an end, that end being object code that is more efficient than |
| 17 |
> offered by binary distributions. In cases where the build process is |
| 18 |
> long or difficult, often binaries are offered (openoffice-bin and |
| 19 |
> phoenix-bin spring to mind), so saying this is a source distribution is |
| 20 |
> false. I firmly beleive Java packages should be offered as binary until |
| 21 |
> gcj is fit to compile them, and that one or other of the JREs should be |
| 22 |
> the default Java environment. |
| 23 |
|
| 24 |
You are incorrect here. |
| 25 |
|
| 26 |
Yes, bytecode is bytecode, however, there are numerous reasons why |
| 27 |
compiling from source makes sense for some packages, not least of which is |
| 28 |
optional run-time dependencies that can be built in (or not) to the final |
| 29 |
JAR. |
| 30 |
|
| 31 |
Also, classes produced by Jikes are often smaller than what's produced by |
| 32 |
Sun's javac. Because of these reasons and others not listed here, |
| 33 |
building from source is not only desireable, it will most definitely |
| 34 |
remain a focus of how we do things. |
| 35 |
|
| 36 |
GCJ/GIJ is planned to be integrated into java-config(1), but will not work |
| 37 |
with a lot of things in the near future until it improves. |
| 38 |
|
| 39 |
Your whole reasoning with GCJ, frankly, I find completely insane. |
| 40 |
|
| 41 |
> It is true that some packages do require a JDK, like Tomcat, but I can't |
| 42 |
> see that as being a reason that all Java packages must require a JDK. It |
| 43 |
> should be pointed out that Tomcat is distributed as a binary, so the JDK |
| 44 |
> is only a runtime dependancy. Why inflict the JDK on users who neither |
| 45 |
> want or need it? |
| 46 |
|
| 47 |
Tomcat is only a binary because it's not currently a source build. That |
| 48 |
will change. Throughout the Java tree I expect to take advantage of the |
| 49 |
'prebuilt' USE flag and make ebuilds binary-or-source where it makes sense |
| 50 |
to do so. |
| 51 |
|
| 52 |
The whole prebuilt USE flag was born out of an RFC I submitted to -core |
| 53 |
long ago. |
| 54 |
|
| 55 |
> |
| 56 |
> Well, thats my rant of the day over with :) |
| 57 |
> |
| 58 |
|
| 59 |
I need reasoned feedback, not rants. This isn't even an RFC yet, so |
| 60 |
please chill out. |
| 61 |
|
| 62 |
Cheers, |
| 63 |
Dylan Carlson |
| 64 |
|
| 65 |
Public Key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x708E165F |
| 66 |
Key fingerprint = 3AEA DE38 FE42 15A6 C0E2 730E 3D04 BCC1 708E 165F |
| 67 |
-----BEGIN PGP SIGNATURE----- |
| 68 |
Version: GnuPG v1.2.1 (GNU/Linux) |
| 69 |
|
| 70 |
iD8DBQE+yq8nPQS8wXCOFl8RAqLSAJwOa02AMPQnqDqtlkuRtXb1qReEywCfXzS5 |
| 71 |
Wx3KeRxny6cmUofMp58mDRo= |
| 72 |
=9oqR |
| 73 |
-----END PGP SIGNATURE----- |
| 74 |
|
| 75 |
|
| 76 |
-- |
| 77 |
gentoo-dev@g.o mailing list |
Archives