Re: automake/514: check_JAVA files are always compiled

[Dalibor Topic]

Thomas Schwinge wrote:

> Hello!
>
> On Wed, Jan 10, 2007 at 07:35:35PM +0100, Ralf Wildenhues wrote:
>  
>
> > * Roberto Bagnara wrote on Fri, Dec 22, 2006 at 03:17:21PM CET:
> >    
> >
> > > The subject says all.  Is there any workaround?
> > >      
> > >
> > > check_JAVA files are always compiled, not only in case of `make check'.
> > >      
> > Quoting 'info Automake Java':
> > |    Any `.java' files listed in a `_JAVA' variable will be compiled with
> > | `JAVAC' at build time.  By default, `.java' files are not included in
> > | the distribution, you should use the `dist_' prefix to distribute them.
> > [...]
> > |    Currently Automake enforces the restriction that only one `_JAVA'
> > | primary can be used in a given `Makefile.am'.  The reason for this
> > | restriction is that, in general, it isn't possible to know which
> > | `.class' files were generated from which `.java' files, so it would be
> > | impossible to know which files to install where.  For instance, a
> > | `.java' file can define multiple classes; the resulting `.class' file
> > | names cannot be predicted without parsing the `.java' file.
> >
> > Seems it's working as documented, no?
> >
> > No, I don't know why this limitation exists, or what would be needed to
> > lift it.  I don't know Automake's java support very well.
> >    
>
> I confirm that compiling a Java source file (`.java') may emit more than
> one byte-code file (`.class') with unpredictable names as long as the
> source files are not parsed.
>
> What about the following idea: before compiling the source files, a new
> temporary directory is created and the compilation is done in there.
> Then every newly created file must have been created from the previous
> compilation process and can thus be associated with the just-compiled
> source file.  After the compilation the resulting `.class' files are
> moved to the main build directory, maintaining created subdirectories.
>
> Such a mechanism could also help for other ``producers'' of object files
> or other intermediate files and will certainly be handy if a versatile
> mechanism of dependency tracking is to be implemented for Automake.
> (Think, for example, about code generators that create C files and
> accompanying header files from some sort of definition language.)
>  
While we're talking about improving Java support in automake, I'd 
suggest a low fruit target:

Automake compiles all sources on the command line in the same command 
invocation. Since
Java class libraries tend to be more or less deeply nested beasts, with 
very long file names like


   org/omg/PortableInterceptor/ORBInitInfoPackage/*DuplicateNameHelper.java
   
<http://java.sun.com/javase/6/docs/api/org/omg/PortableInterceptor/ORBInitInfoPackage/DuplicateNameHelper.html>*

which leads to trouble with maximum shell command line lenght when 
compiling a large class library. I'd suggest
creating a list of files to compile via consecutive echo calls first, 
and then calling $JAVAC with the option
@name_of_that_file_list which works around that problem. That would make 
automake's Java support
more useful for compilation of java class libraries in projects like GNU 
Classpath & Kaffe.

Another weird issue is that automake tries to install the class files, 
while in general it's preferred to
install them zipped up as JAR files. The analogon in the C world is 
single object files,
and an object file archive.

cheers,
dalibor topic