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

[Greg Ward]

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.

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).


> Inter-jar dependencies are a trickier problem, as others have noted

> in their responses.  SCons could make a best-effort approach at

> identifying them via import statements,


Waste of time IMHO. That's maybe 70% correct, so why bother? If you're
not going to implement a correct solution, I don't see the point. And
the only way to do it correctly is to parse the source code *and*
understand the type system. (You have to know what it means to
subclass something, what it means to implement an interface, what
method arguments and instance variables are... the works. It's much
more difficult than simply scanning for "import" or "#include".)


> but in the end, if your .jar

> files end up in a well-known build outputs directory, then specify

> that as the command-line target in your builds, and every .jar that

> needs to be rebuilt, will get rebuilt.


Yep.

-- 
Greg Ward                                http://www.gerg.ca/