Paul Eggert <[EMAIL PROTECTED]> writes:
> > From: [EMAIL PROTECTED]
> > Date: 08 Nov 2002 09:40:21 +0000
> >
> > Would the auto* tool maintainers be interested in hearing more about
> > automakejar's functionality? Perhaps with a view to implementing
> > similar functionality in automake?
>
> Maybe. Do you have a URL or brief summary explaining the advantages
> of automakejar? Would it be easy to fold its ideas into Automake, or
> are we really talking about a separate tool here?
>
> (This sounds more like an Automake issue so I've trimmed the CC: line.)
We don't have a webpage, it's a simple tool and it's not widely used
(just a few java projects). Someone has offered to right a manual but
it hasn't happened yet.
I hope you'll excuse me if I write a bit more about it here.
I've never used automake on a project. automakejar came out of an
aborted attempt to use automake.
Essentially automakejar does one very simple thing in as simple a way
as is possible. It allows the programmer to create a java library
file by declaring the dependancys that make up that file.
Automake allows that as well, but not in such a simple way.
Here's a concrete example of what automakejar does. This is taken
from the paperclips project (a GNU project). It builds the paperclips
jar file. The # comments are not part of the template:
paperclips.jar:
sourcedir=$(SOURCEDIR) # where the source files can be found
sourcefiles=$(SOURCEFILES) # a 'make' list of source files
classpath=$(LIBRARYS) # dependant librarys
classesdest=classes
otherfiles=META-INF/mime.types # other dependant files
manifest=$(PROJECTROOT)/lib/manifest.mf # special library descriptor
These are the make rules that are produced by automakejar from the
above template:
paperclips_jar_sourcedir=$(SOURCEDIR)
paperclips_jar_sourcefiles=$(SOURCEFILES)
paperclips_jar_classpath=$(LIBRARYS)
paperclips_jar_classesdest=classes
paperclips_jar_otherfiles=META-INF/mime.types
paperclips_jar_manifest=$(PROJECTROOT)/lib/manifest.mf
paperclips_jar_debugclasses=$(paperclips_jar_sourcefiles:.java=.class)
paperclips_jar_classfiles=$(paperclips_jar_debugclasses:$(paperclips_jar_sourcedir)%=$(paperclips_jar_classesdest)%)
paperclips.jar:
paperclips.jar: paperclips-init $(paperclips_jar_classfiles) paperclips-compilation
$(paperclips_jar_otherfiles) $(paperclips_jar_manifest)
$(JAR) cf$(if $(paperclips_jar_manifest),m) paperclips.jar
$(paperclips_jar_manifest) $(paperclips_jar_otherfiles) -C
$(paperclips_jar_classesdest) .
.PHONY: paperclips-init paperclips-compilation
paperclips-init:
echo > filelist
paperclips-compilation: $(paperclips_jar_classesdest)
$(if $(shell cat filelist),$(JAVAC) $(JAVAC_OPTS) -d
$(paperclips_jar_classesdest) -classpath $(call PATHMK,$(paperclips_jar_classesdest)
$(call PATHMK,$(paperclips_jar_classpath))) @filelist)
$(paperclips_jar_classesdest):
mkdir $@
$(paperclips_jar_classesdest)/%.class: $(paperclips_jar_sourcedir)/%.java
@echo $? >> filelist
These rules facilitate "normal" make behaviour for java. ie: you
update a file and run make again and make detects that it's changed,
recompiles just that file and then rebuilds the jar file.
The tricky thing about java is that you don't have a direct source
file -> object file relationship. When you compile a source file
it is not possible to state (on the command line) what the resulting
object file will be called, the object file is always called by the
fully qualified name of the class declared within the source file.
automakejar takes that out of the programmers hands by concentrating
on the jar file (which is how java programs are in practice
delivered). The class files are generated as an "internal", hidden
step.
One concrete difference between automakejar and automake is that
automakejar facilitates batch compilation whilst, as I understand it,
automake does not.
java's batch compilation is quite clever, you can pass the java
compiler (at least all the implementations I'm aware of and that
includes GCJ) an @file, which is a file containing the names of
source files to be compiled. The java compiler will then compile all
those files.
Therefore, for a project java compile, make should produce a list of
all the files that have been touched since the last compile (by
comparing source file -> class file) and add those files to an @file
and then run the compiler passing it the @file.
Unfortunately, I found this behaviour quite difficult to generate
with make which is why some of the make rules that automakejar builds
look complicated.
That's roughly what it's doing though.
>From what I know about automake I'm fairly sure that this kind of
behaviour could be added, but I'm not sure I'd even know how to start.
Nic
