[Scons-dev] File-based build tools will never handle Java

[Chris BeHanna]

On Sep 6, 2012, at 13:21 , Greg Ward <greg at gerg.ca> wrote:


> On 06 September 2012, Chris BeHanna said:

>> On Sep 5, 2012, at 21:20 , Greg Ward <greg at gerg.ca> wrote:

>> 

>>> OK, I finally sat down and did a little thought experiment, and have

>>> convinced myself that file-based buld tools will never handle Java.

>>> The reason? Dependency cycles.

>> 

>> I wonder if it's even anything to worry about.  Have a .jar as

>> output and a defined set of .java files as input, and in the middle,

>> it's sausage-making.  Don't even worry about tracking (or caching)

>> .class files; just track the dependency of a .jar file to its .java

>> files.  As long as all of the .class files (even those that end up

>> being generated anonymously) end up in a predetermined location over

>> which you run the jar command, you should be good to go.

> 

> Yup, that's exactly what I ended up doing at my old job, where I

> cobbled together a moderately scary mixed C++/Java build system using

> SCons and a lot of hard work. It was harder than it should have been,

> mainly because I had to write a custom Node class to represent the set

> of input files. SCons is just too slow when you give it 15,000 input

> files, but it was tolerable when I shrank it down to ~75 sets of input

> files. Writing custom Node classes that do not subclass File is a

> PITA.


	:nod:

	That performance hit is why $EMPLOYER is abandoning SCons.  :-(


> However, something valuable is lost when you simplify dependencies so

> dramatically. Specifically, I implemented incremental testing, which

> was a win, but not nearly as much of a win as it could have been. E.g.

> if you modify a source file in a low-level component that everything

> else depends on, then you end up recompiling the world (no big deal:

> javac is fast enough), and re-running all the tests (not nice: the

> whole test suite is 20-30 min).


	Can the tests be broken down to a per-jar basis?  If so, and if you can identify the jar or jars that changed, then you only run the tests for the jars that changed.

-- 
Chris BeHanna
chris at behanna.org