[kepler-dev] Nightly Builds

[Christopher Hylands Brooks]

[I changed the Subject line]  

Matt wrote:
> [I (Christopher) wrote: ]
> > * How are nightly builds and tests handled right now?  Forgive my
> > ignorance on this, it might be apparent from the code, I just have
> > not looked.
> 
> We don't have a nightly build.  We should get one :)  I know your 
> existing makefile permits this.  Somtime I would like to discuss the 
> Makefile with you and try to figure out why it builds so much more 
> slowly than the ant build that I wrote.  Then it would make more sense 
> to use it directly for the nightly build.

BTW - "cd $PTII; make fast" should be much faster than "cd $PTII; make".

The $PTII/adm/gen-3.1/makefile is what I use to run the nightly build.
It is a very gross file, I don't recommend looking at it.

The reason it is gross is that it works under Cygwin and Solaris, and
it does multiple builds on remote machines.

However, what it does is conceptually simple:
1. In a directory that has a preexisting Ptolemy II CVS tree, do
      cd $PTII
      cvs update -Pd
      make clean fast
   and run the tests.
   In the nightly build, the tests are listed in a strange order to
   ferret out package dependencies, but in principle
   (cd $PTII; make tests) should work.

2. Build a release by excluding things we don't ship, make a few
   modifications to configurations (exclude references to things
   that do not ship)

3. Untar the release elsewhere, build (with a different java and make)
   and run tests.

4. Run the very long codegen tests and send email about it to 
   only a few developers.


So, no matter how you build, you can still do step 1 above.

BTW - If you want to quickly build Ptolemy as part of that, you can
do 'make clean fast'

The other steps are also not particularly make-centric.

I strongly encourage you to set up a nightly build, it is a big win.

Our nightly build is available at
http://chess.eecs.berkeley.edu/ptexternal/nightly/index.htm

http://chess.eecs.berkeley.edu/ptexternal/nightly/coverage.html
is a large table that shows the code coverage for the Java classes.


BTW - With regard to JUnit vs. Jacl, JUnit is much more of an industry
wide standard, so going with it is appropriate.

The one advantage of using Jacl, a 100% Java implementation of a
subset of Tcl) is that Jacl is interpreted, which makes writing tests
a little easier.  I find it is easier to create small test fragments
by typing at a command line prompt and then piece together a larger
test file.

There are many more cool JUnit tools out there than there are Jacl
tools. 

-Christopher