On Thu, Sep 6, 2012 at 12:59 PM, Chris BeHanna <[email protected]> wrote: > On Sep 5, 2012, at 21:20 , Greg Ward <[email protected]> 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 _______________________________________________ Scons-dev mailing list [email protected] http://two.pairlist.net/mailman/listinfo/scons-dev
