Riccardo wrote: >Dalibor Topic <[EMAIL PROTECTED]> wrote: >> Alternatively, we could remove GNU Classpath from our tree, and require >> the user to build it first, and then build Kaffe using that version. I >> do not know if jikes can parse bytecode from compilers for Java 1.5, but >> that's the only way I'd see jikes support remaining available. That'd be >> my preferred option for 1.1.8, fwiw. :) > >although on the long run we need to tackle 1.5 issues, I'd procrastinate >that to 1.1.9 and have 1.1.8 out with our current stuff, at the expense of >not having an up-to-date classpath.
I agree with Riccardo at this point. Why don't we put 1.1.8 quickly, and then tackle 1.5 issue or classpath 0.95 issue later THIS year ;-) I don't want to see so many mail post saying 'I get 1.1.7, and does not work, etc...' so many times. >Still, I don't know about jikes and kjc either. Do you think egcj would be >fast? how is it memory consumption? Is it maybe able to compile claspath >using split compilation? These could be intresting things to continue >native builds on our aging test platforms (that is - my boxen) Since I was a user for kjc for long time, I don't mind if I have to use java based java compiler again. Things what I mind are, current classpath build does not allow us (or me?) to separate its build for machine dependent (MD) part and independent (MI) part. I understand jni part of classpath should be MD, and hence we have to compile it on the target (or, setup cross compilation) but the jar part should be MI, and we need not to do this compilation everytime. Currently, only glibj.zip can be passed as an argument to the kaffe build, and tools.jar or some other jar files are compiled as like as they are MD. If we (or they) can provide some way to separate MD from MI, Riccardo's concerern should not be impactful for us who wants to build kaffe on slower/older machines. Kiyo _______________________________________________ kaffe mailing list [email protected] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
