[Biojava-dev] Build system changes

[Thomas Down]

Once upon a time, Matthew Pocock wrote:
>  --- Thomas Down <thomas at derkholm.net> wrote: > Hi...
> > 
> > I've been having a bit of a tidy up in the build.xml
> > file.
> It needed it :)
> 
> > For example:
> > 
> >      ant -Dtest.subtree=org/biojava/bio/symbol
> > runtests
> 
> >      ant -Dtest.subtree=org/biojava/bio/seq/**
> > runtests
> 
> Very cool. I'll be playing with this.

Quicker, less painful test runs == more testing -- that's
the theory, anyway.  The other thing that's worthwhile in principle
is running all the tests in a single VM.  Unfortunately, when
I tried that I ran into bad memory trouble.  The ideal solution
would be to run groups of tests together, but this might mean we
have to write our own test runner.

> > I'm also considering a slightly more radical shakeup
> > of the build
> > system.  Currently, when a build is launched, all
> > the source is
> > copied into ant-build before compilation.  This was
> > a good idea
> > when we had separate core and jdk1.4 sources, but
> > isn't needed
> > now.  As far as I can tell, it just slows the build
> > down and
> > causes problems with tools like the jEdit ErrorList
> > plugin.
> 
> It causes me grief with IDEAL - debugging tries to
> edit the coppies, not the original source. I think now
> that the source trees are prety much as you would
> expect (seperate trees for tests, demos etc.), this is
> less of an issue. The only other gotcha is if people
> have mixed resources in with .java files - could you
> double-check this?

Okay, three votes in favour, none against so far -- looks
like this is going to happen.

Re: resources, I'm fairly sure that the main source tree is
fine.  The test tree isn't.  I'm pretty sure the ANT javac
task only tries to compile .java files, so this shouldn't be
a big deal, but it's arguably nicer to have a separate
tree (test-resources? test-data?) for datafiles used in tests.
I might implement that while I'm poking around.

> One other build thing - last time I poked arround in
> it, I started making each module compile / test
> against the .jar of its dependancies - this ensures
> that the .jar files we make contain the stuff we think
> they do. Not sure if I carried this all the way

Okay, I'll look into this.

One question: how determined are you to keep the SableCC grammars
in a separate jar file?  They get build alongside biojava, and
aren't useful on their own, so why not keep them in the main jar.
One less item on my CLASSPATH...

     Thomas.