[kepler-dev] Re: Nightly Builds
Stephen Andrew Neuendorffer
neuendor at eecs.berkeley.edu
Thu Mar 18 11:11:31 PST 2004
make fast basically runs one javac for each directory... But you still
have a javac process and a recursive make process for every directory.
Given a large number of directories, that's still alot of processes...
At 10:06 AM 3/18/2004 -0900, Matt Jones wrote:
>So, even using "make fast" the build is far slower using "make" than
>"ant". On my P4 3.06Ghz PII with 1GB ram, these are the stats I get:
>[jones at snow ptII3.0.2]$ time make clean fast
>[jones at snow kepler]$ time ant -f build-ptolemy.xml clean install
>Granted, this isn't a totally fair comparison, because the make does more
>stuff than the ant build. But the ant build does everything *needed* in a
>normal edit/compile/debug cycle, and in this context the difference
>between 23 seconds and over six minutes is huge. My hunch is that make is
>lauching javac separately for every java file, which incurs huge per-file
>overhead, while ant does its compilation of all java files within a single
>javac invocation. But that's just a hunch on my part as I haven;t looked
>into it in detail. And its not just your makefile -- my experience has
>been that compiling java files using make is slow under all projects where
>I've seen it used.
>Thanks for your insights into why this might be,
>Christopher Hylands Brooks wrote:
>>[I changed the Subject line]
>>>[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
>>>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
>>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
>>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
>>There are many more cool JUnit tools out there than there are Jacl
>Matt Jones jones at nceas.ucsb.edu
>http://www.nceas.ucsb.edu/ Fax: 425-920-2439 Ph: 907-789-0496
>National Center for Ecological Analysis and Synthesis (NCEAS)
>University of California Santa Barbara
>Interested in ecological informatics? http://www.ecoinformatics.org
>kepler-dev mailing list
>kepler-dev at ecoinformatics.org
More information about the Kepler-dev