Re: [Cp-tools-discuss] build

[Nic Ferrier]

Mark Wielaard <address@hidden> writes:

> I really want to take a good look at this automakejar stuff so if you 
> are to busy then I would be more then happy to do it. Just point me to 
> the latest version and I read the mail archive which if I remember 
> correctly talked a bit about it... 

Note: automakejar was written because I didn't like the way automake 
required one makefile per source directory. Hopefully it's a stop gap
solution for having automake provide some of the same
facilities. Having said that, it does work quite well.


The latest version of automakejar is in the paperclips cvs. The
version elsewhere works but there is a fix for a particular feature in
the paperclips cvs version.

The tool does not have it's own project or webpage yet.


> Yes, found it, the thread starting at: 
> http://mail.gnu.org/pipermail/cp-tools-discuss/2002-April/000085.html 

It's very simple. An automakejar target looks a lot like a make
targets (Julian doesn't like that but I haven't got round to changing
automakejar yet). They are designed to generate a single jar file.

An automakejar target might look like this (taken from the jaxp module
in classpathx):

gnujaxp.jar:
        sourcedir=$(SOURCEDIR)
        sourcefiles=$(SOURCEFILES)
        classpath=$(wildcard $(PROJECTROOT)lib/*.jar)
        classesdest=classes
        otherfiles=$(SUPPORTFILES)
        manifest=$(PROJECTROOT)/manifest.mf


automakejar processes the Makefile.aj (which contains the automakejar
targets) and outputs a file named by your pleasure:

   automakejar Makefile.in

*produces* the Makefile.in (this is a bit rubbish, we'd like to
 intelligently work out when to generate the Makefile.in, again, I
 haven't got round to that yet).

The targets specify:

- the source files directory
This is the base dir for all source code, in gjdoc it will be
$(PROJECTROOT)/src presuming $(PROJECTROOT) is set to autoconf's
@SRC@ variable.


- the list of source files (space separated)
This can be achieved by doing a find or using a normal Make soure
file list, Paperclips' list looks like a bit like this:

SOURCEFILES = $(SOURCEDIR)/gnu/paperclips/Paperclips.java \
              $(SOURCEDIR)/gnu/paperclips/Other.java \
              .
              .
              .
              $(SOURCEDIR)/gnu/paperclips/Last.java

But one way of writing the rule directly is done in the activation
module  in ClasspathX:

        sourcefiles=`find $sourcedir -name "*.java" -print`

This is also the same as saying the more Make like:

        sourcefiles=$(shell find $(sourcedir) -name "*.java" -print)

Note that the sourcefile list should only include sourcefiles which
are under the specified sourcedir.


- the classpath elements (space separated)
Again, this can often be generated with a bit of Make:

        classpath=$(wildcard $(PROJECTROOT)/lib/*.jar)

You can also use shell to do an ls of the directory.


- the class file destination
A directory where your compiled class files go.


- otherfiles to be copied into the jar file
These are copied directly into the jar, they are not dependancies.


- manifest
As you'd expect, the manifest of the jar file can be specified.



You can make the automakejar target have dependancies just as you
would in Make:

gnujaxp.jar: some-dependancy-target
        sourcedir=$(SOURCEDIR)
        sourcefiles=$(SOURCEFILES)
        classpath=$(wildcard $(PROJECTROOT)lib/*.jar)
        classesdest=classes
        otherfiles=$(SUPPORTFILES)
        manifest=$(PROJECTROOT)/manifest.mf


The last thing you have to know is what the produced target actually
does. When you call the resulting Makefile with one of these jar
targets the Makefile creates a filelist file with the names of all the
source files that need to be compiled (with simple timestamp depend
tracking) and then calls $(JAVAC) with $(JAVAC_OPTS) on the list
putting the class files into the directory you specified in the
automakejar target (the "classesdest" directory).

Once the files are compiled the Makefile then calls $(JAR) to create
the named jar file with what is in the "classesdest" directory.

And that's it. It works really well because you can get very simply
depend tracking that does 95% of what you want.

Some of the time you have to run:

    make clean all

but mostly you don't.


automakejar does not construct clean targets (because it doesn't
control the whole Makefile) but they are very easy to create given
the explicit specification of automakejar dependancies.

One final thing: automakejar requires some very common variables: 

# Variables which define some useful constants
newline:=\\n
empty:=
space:=$(empty) $(empty)

These are not added to the Makefile by automakejar but probably
should be.


  
> I only have access to Debian GNU/Linux systems though and I am not very 
> interested in getting it to work with non-free VMs. But I am very 
> interested in producing stand alone executables (with gcj). 

Sure. The way I plan to do this is via creating a jar. That, after
all makes some sense.

I may need to alter automakejar so that it can link in with a
particular "main" class.


>  
> > I'm happy to build an automakejar file for this but we need to sort 
> > out these apparent non-free bits. 
>  
> I can build and run it using only the source in CVS plus the 
> com.sun.javadoc package from Classpath with either gcj 3.0 or 3.1 (CVS). 

Cool. That's ok then.... it worried me for a minute.


Nic