Re: [Classpathx-discuss] ANT and JUNIT issues (automake???)

[Olivier LF]

On Tue, Dec 04, 2001 at 10:31:10AM -0800, David Brownell wrote:
> >     Shared libraries (for gcj), automake does all the work with only
> >     3 lines of input.
> 
> I'd be interested in seeing ClasspathX adopt automake (what
> version though??) if it it solves those problems.  So I'd be interested
> in seeing your gnu.crypto autoconf/automake files.

You'll need recent versions, I have:

   autoconf (GNU Autoconf) 2.52e
   automake (GNU automake) 1.5a

from CVS, maybe a month ago. You only need these tools as a developer to
modify Makfile.am and configure.in files. Users don't need anything
(except shell and make of course!).

I'll checkout the latest gnu-crypto and tune it against this version.
Sorry I am runing out of time this week. I'll post something over the 
weekend.

> >   compilers. Using gcj, I am not sure you can compile all sources in a 
> >   single (.o) file. In any case that does not look right. Typically
> >   you'd like one object per package. Also automake generates the classic
> >   one java file --> one object type of compilation that is not optimum
> >   either.
> 
> Hmm, I'm not sure what you mean "one object per package".  I know
> there was a "one shared library per package" proposal in GCJ-land
> a while back, also a "jarfile-to-SharedLibrary" mode in GCJ which is
> a rather different model.
> 
> Could you elaborate?

One (.o) file per java package. I haven't try this but I am sure you can
do something along these lines:

   gcj -o pkg1.o -c pkg1/*.java

That is to compile all the classes for a package into a single object
file. I am not sure of the exact flags but the idea is to compile more than 
one class in a single invocation of gcj (therefore in a single object
file). This boost up the compilation because the compiler is less likely 
to scan referenced classes over and over again.
During java compilation, the compiler must scan all classes referenced
by the class it is currently compiling. Typically, classes in the same
package inter-reference themselves a lot. If each class is compiled in a 
separate invocation of the compiler, then chance are that most of the
other classes in the package will be scanned over and over again.

A bit of arithmetic, let's assume 20 classes in a package that all
reference themselves:

   gcj -o pkg1.o -c pkg1/*.java    

   ==>  20 scans


   for f in `find pkg1 -name '*.java'`; do
      gcj -c $f
   done
   
   ==> 400 (20*20) classes scanned!!!

of course this is less than optimum. Actually, this is nothing specific
to gcj, other java compiler have the same issue. It just highlights that
bulk compilation in java is a good idea when compilation time becomes 
an issue.

Automake generates a Makefile that compiles java files one at a time.
Obviously it is less than perfect in that regard. However, on medium size 
projects with gcj or jikes this is not really an issue because they are still
reasonably fast.
Using Sun javac can be very frustrating however but mostly because the VM is
started and stoped for each file... That does take a long... long...
time!

However I would still recommend configure/automake approach. The goal of 
these two softwares is not so much to be optimum from the developpers 
perspective than to help users with little knowlegde of the
software and its requirements to build it successfully.

configure and automake produce very portable code (Makefile and shell
scripts) that works on a very large number of platforms. configure can
detects compilers and flags to use. This is especially usefull for native 
shared libraries. Should I use "-fPIC" while building on HP-UX? I really 
have no ideas, fortunatly configure knows all of that for me and will 
append whatever flags this platform requires. These kind of details 
greatly increase the chance of users building the software successfully 
out of the box. Whether it takes 15 secondes or 5 minutes is mostly 
irrelevant. If it succeeds at first try it will be a complet success
from their point of vue.

This is also very good for people maintaining GNU/Linux distributions. 
Configure gives them a lot of options to prepare packages for different
distributions.


For us writing the software, I would really recommend ANT. ANT is
the best tool to recompile small portion of a project at an increadible
speed. ANT scan the source tree, find files that have been modified
and does a bulk compilation of just that subset in its own VM.
You just can't beat that approach with a Makefile, unless one writes a
shell script that does the dependency check and invoke the script from
the Makefile but really it does not worse the effort and that wouldn't
be as fast anyway because ANT also build the jar in its VM and optimize 
"file copy" tasks as well!


olivier

-- 
----------------------------------------------------------------------
Olivier Louchart-Fletcher
Email: address@hidden