-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Thomas Fitzsimmons wrote: > In the meantime it would be very useful to create a pure bytecode > eclipse-ecj package, buildable by gcj -C, for distribution by > jpackage.org. I wanted to do this when I first submitted java-gcj- > compat to JPackage but I never got around to it. All the logic will be > in the Rawhide Eclipse spec file, since we bootstrap ecj using gcj -C. It shouldn't be too hard to do this. The question then becomes: what is necessary for gcj to pick up ecj as the compiler? As I recall from eclipse.spec, it just set a .so in its LD_LIBRARY_PATH. This won't work for the bytecode-only version. I should look myself, but because of the issues stated, I don't have gcj-compat installed on my system at this time. Also, I guess katana has been dumped for fc4 and beyond? So what is the plan for nativifying jars from now on? Ideally, I wish that it was transparent to other non-native javac's. For example, it would be handled by gcj's javac script and then a macro (or whatever) could be added to pick up any extra files produced. >>A minor issue seems to be that classpathx-mail requires >>classpath-inetlib-javadoc, only I can't find a separate >>classpath-inetlib package. Instead, it seems to be in the >>classpathx-mail rpm, in which case no package can provide the >>classpath-inetlib-javadoc dependency that is needed. Is this classpath-inetlib-javadoc dependency erroneous? Remember that inetlib got merged in with classpathx-mail. I seem to remember that there was a separate classpath-inetlib package that used to be in fedora development. In any case, it's no longer there, nor did it find its way into JPackage. > I'm working on a patch that will merge Jessie into GNU Classpath/libgcj > which will eliminate this dependency. You mentioned that the ecj stuff was targeted for fc5. Is this also targeted for much later? In that case, I don't think it would hurt to remove jessie as a requirement for gcj-compat (for my purposes at least). After all, any package which needs what it provides will pull it in separately anyway. What package required this that it was necessary to put it into the core? It is only a provider for jce, when jce is provided by gnu-crypto. Perhaps gnu-crypto should require a provider (virtual) and jessie should provide this. The point is that no core package needs a crypto provider as far as I can tell, so there's not much of a point tying it to the core system. - -- Sincerely, David Walluck <david@xxxxxxxx> -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org iD8DBQFCeY9/arJDwJ6gwowRApXSAJ0Srs8qYnfYaPqbEaGLRJ4E0Z0xgwCfUhW8 SVqN1qwB6R1YnLIzo7eYQBc= =lAbU -----END PGP SIGNATURE-----
