Audrius Meskauskas wrote:
OK, the previous error can be fixed by the good kicking of the build
system with:
[EMAIL PROTECTED] cp-tools]# gcj
--classpath=.:/usr/share/java/bytecode.jar:/usr/share/java/asm.jar
-fassume-compiled -I./src -I -Isrc/jars/bytecode.jar
-Isrc/jars/asm.jar -I. -g -O2 -o localegen --main=gnu.localegen.Main
-Dgnu.gcj.runtime.VMClassLoader.library_control=never
src/gnu/ldml/AliasElement.o src/gnu/ldml/Analyzer.o
src/gnu/ldml/Constants.o src/gnu/ldml/DataElement.o
src/gnu/ldml/DetailedListElement.o src/gnu/ldml/Element.o
src/gnu/ldml/ExpansionElement.o src/gnu/ldml/ListDataElement.o
src/gnu/ldml/OrderedListBaseElement.o
src/gnu/ldml/OrderedListElement.o src/gnu/ldml/ParseException.o
src/gnu/ldml/Parser.o src/gnu/ldml/ResetElement.o
src/gnu/localegen/CollationInterpreter.o
src/gnu/localegen/JavaGenerator.o src/gnu/localegen/Main.o
src/gnu/localegen/PropertiesGenerator.java
after error and typing "make" again, and the build goes till finish!
However only in the case when the very old ASM 1.5.3 is used. It does
not compile with the recent 3.0 and also with any version of the 2.*.
This is also not written in INSTALL.
Conclusions:
1. We need instructions how to make the bytecode.jar. It does not
appear automatically.
2. We need to specify the currently used versions of ASM and probably
of KAWA also.
3. We probably need to fix the build scripts to prevent the build
problem, described above.
Audrius.
The dependency on bytecode.jar was I thought to go away when the new
javah/javap tool that also provided compilable assembly code appeared.
I haven't seen it yet though so I don't know whether to spend some of my
copious spare time on this project or not. Yes, I have time to work on
this but I've not followed up on it due to what I perceive to be a much
better replacement coming at some point.
A while back I wanted to move gjdoc into cp-tools so we could stop with
the whole maintaining multiple build scripts but with most of the active
development happening over there I didn't see much support for this.
Tom apparently wants to move it into classpath where I think we run the
risk of the tools becoming dependent upon Classpath specifics rather
than working anywhere there is a suitable java environment. However
there are also places where tool integration with the core library is
beneficial, I believe in terms of RMI.
I haven't updated to the latest Fedora and I don't have a jpackage based
system for java libraries. So fixing the build so it is as flawless as
it should be is difficult for me.
I think we should update our code, some of it is recent, to use the
newest version of ASM only and remove our dependency on KAWA
completely. We need a testsuite for our tools to ensure they work and
that changes don't break them.
Brian
_______________________________________________
Cp-tools-discuss mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/cp-tools-discuss
