Re: Regarding the JAVA primary

[Steffen Dettmer]

On Mon, Apr 19, 2010 at 8:25 PM, John Calcote <address@hidden> wrote:
 [...]
> Builds in the Java world generally specify source files found
> within a subtree using a globbing mechanism, with optionally
> specified inclusions and exclusions.

Yes, they do. BTW, does anyone know why?

With some sarcasm someone could tell that it is done in this way
because with Java you need to make heaps of files (e.g. one for
every public exception), but maybe it has a good reason?

We use some very old and surely bad custom automake rules to
compile java sources. Ages ago we also had some wildcard (`find')
rules (inspired by ant assuming `this would be the good way to
go'). Those rules collected the files, but we changed them to use
a list of file names, which seemed much cleaner and solved some
issues (which of course could had been solved in other ways,
too).

One motivation for this change was that our make rules that
generated the exception source code files (many differing more or
less just in the name and some `String name ...') and people
forgot to add the files, so if existing for them they had been
built but not for others where the files were not updated (and
the new gensrc files were missing). This resulted in an
incomplete jar file and unfortunately when using this jar a
compilation error was flagged out in the wrong package... unit
tests did not helped because of course also missing in the
incomplete jars (and the make check scheme we used also used a
wildcard approach to collect the unit tests to be executed).
Strange things happend when switching between branches (where
typically the number and kind of exceptions changed etc).

I disliked that when by some problem almost all sources would get
lost in a sandbox (e.g. if switching to a bad / incomplete tag),
make (and even make check!) succeeded.

On `tree conflicts' (one changed a file, another moved it) it
could even happen to have two times the same functionality in a
jar...

To build a list of files why not open Makefile.am in $EDITOR,
like vim or emacs, and insert the file list here (in vim, you may
start a line `java_source = \' and on the next blank line use
`!!find . -name "*.java" -exec echo "{}" "\\" ";"'
which works except for the last file, which ends with a `\'.). No
need to make this at make run time, or is there any?

By this, cvs diff (or whichever SCM tool is used) easily shows
the included files which is easier to review I think.

Using wildcards IMHO means to logically `include' the directory
contents to the Makefile. I think you cannot even use it as
dependency (and thus I'd guess the jars would be resigned on each
make run, even if no file changed?).

What is the advantage of using find magic and make time?

How do you handle your java.in files?
How are you safe to get old generated files out the jar (if
removed from gensrc, they still are in builddir and the make
clean rule may not even take it any longer - how to notice?).

I'm afraid the find/wildcard approach only works for simple
builds - but those could also be done by ant I think...

> I'm not stealing this concept entirely from ant.

(yeah strange tool that, but different topic :-))

oki,

Steffen