Re: [Cp-tools-discuss] Build succeeded, but...

[Brian Jones]

Audrius Meskauskas wrote:

> OK, the previous error can be fixed by the good kicking of the build 
> system with:
>
> address@hidden 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