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

[Chris BeHanna]

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.

> 

> Short version: in Java, cycles between source files in the same

> package are commonplace and often impossible to avoid. Because

> interface and implementation are in the same file, that leads to DAG

> cycles, which any DAG-of-files-based build tool (make, SCons, tup,

> waf, ...) will reject. (Yes, I know that SCons nodes don't have to be

> files. But writing non-File Nodes is so painful that SCons might as

> well have that restriction.)

> 

> Why? Because packages (directories of source files) fill much the same

> role in Java that modules do in Python or C. We don't sneer at Python

> code where two functions in the same module call each other, so don't

> mock Java developers who put a cycle in one package. Save your mockery

> for the ones who put cycles *between* packages. ;-)


	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.

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

	Am I missing something?

-- 
Chris BeHanna
chris at behanna.org