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?
--
Chris BeHanna
[email protected]
_______________________________________________
Scons-dev mailing list
[email protected]
http://two.pairlist.net/mailman/listinfo/scons-dev
