bug#9088: the jar fragment

[Michael Zucchi]

Hi,

This is my current work on the '.jar' fragment.  The rest is just there
to create a working makefile, but the focus of this post is solely on
the 'foo.jar' target fragment.

In-so-far as jar generation goes, this should be 'portable and feature
complete'.
1) Out of source building.
2) In-source tree/generated files
3) 'alternative-root relative' and 'makefile relative' files
4) optional in-source/generated manifest
5) optional main entry point

I have not used (to my knowledge) any gnu-makeisms in the
automake-template-part, and also aimed for portable sh and sed usage.
It should include all the dependencies it needs (at this point).

I presume 'spaces in file names' just isn't supported in general.

(the automake naming conventions and things like the 'build' dir are not
yet done, but are trivial to alter, I need to review all of your
provided information some more first).

It turned out that merging resources/sources wasn't a good idea: it
added complexity and lead to poor dependency behaviour (e.g. add a text
file - compile every jar), so I split them out again.  And despite
suggesting it, I actually don't see any need for the SOURCES_PREFIX at
this point.

Because of the way the jar command-line works I decided to add direct
support for the manifest and 'main method' (entry point).  I think this
works out cleaner/simpler (and is easier to use) than trying to allow
the user to supply a custom jar command line.  _JARFLAGS could still be
used for a couple of aesoteric options.

Background/justification:

Generating a simple jar file is like tar:
 jar cf foo.jar files ...
Adding a manifest requires strict ordering:
 jar cfm foo.jar manifest.txt files ...
 jar cmf manifest.txt foo.jar files ...
Same with also adding a main class entry point:
 jar cfme foo.jar manifest.txt au.notzed.Main files ...
But this doesn't work:
 jar c -f foo.jar -e au.notzed.Main -m manifest.txt files ...

i.e. the last example could be easily parametrised and allow a
'_JARFLAGS' variable to include these things, but as that isn't the way
jar works, it can't.

The shell script isn't very complicated, it's just bulky.  I fully
indented it for clarity.  The vpath walk is required several times, and
it has to look-up prefixes on every file.  I basically followed how the
java.am did it.

The prefix handling stuff is about one of about 10 different solutions I
tried, everything from awk to sed to plain shell, case statements, etc.
 None were any much smaller than the others and this one should be one
of the most portable, and unlike some it requires no automake.in setup.

I have another version which doesn't require sed for the prefix
handling, but i'm not sure how portable the substring/length stuff is (I
spent quite a while searching to try and find out, but search engines
aren't very useful for looking this technical stuff up any more).

It just needs the length and sub-string functions:  prefix=${n:0:${#r}};
relname=${n:${#r}}

If those are ok to use it might be a bit more efficient/readable, not
needing to run sed.

 !Z