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

[Gary Oberbrunner]

On Thu, Sep 6, 2012 at 12:59 PM, Chris BeHanna <chris at behanna.org> wrote:

> 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?


I think that idea has come up before.  It totally makes sense to me,
if that's what fits with Java.  There may be some minor issues with
exactly what class files get put into the jar, but worst case SCons
could always compile each java file set into a clean temp subdir, to
ensure that all the .class files that are generated make it into the
jar, and only those.

-- 
Gary