On Thursday 06 September 2012 13:47:02 Greg Ward wrote:
> On 06 September 2012, Gary Oberbrunner said:
> > I don't think this is really a problem, or doesn't have to be. In
> > SCons there are no dependencies *between* source files; only from
> > object (.class files) to source (the object depends on the source(s)).
> >
> > And the jar depends on the class files. So I don't see how call
> >
> > graph complexities lead to build dependency cycles. If any of the
> > source files change, certain objects and jars depend on those and have
> > to be rebuilt. The real problem (at least as I understand it, I'm not
> > a Java guy) is the fact that each .java produces unpredictable
> > outputs. Am I correct about this, or are there actually real
> > unavoidable build dependency cycles?
>
> As Mark Flacy said, you are unfortunately incorrect here. Let me give
> a concrete example (taken from the little hg repository I mentioned
> earlier today: http://hg.gerg.ca/sample-java, in cycle/).
>
> Container.java:
> """
> package cycle;
>
> class Container {
> void add(Item item) {
> }
> }
> """
>
> Item.java:
> """
> package cycle;
>
> class Item {
> Container parent;
> }
> """
>
> You cannot compile these two files independently. Either javac will
> discover the other source file and compile it implicitly, or you must
> list both files on the javac command line. (IMHO the latter is by far
> preferable. javac's implicit compilation might have seemed like a good
> idea at the time, but I'm convinced that it's a bad thing to rely on.)
>
> What's really funny is that the DAG depends on how you run javac. No,
> seriously. I *believe* that javac's default results in this DAG:
>
> Container.class <---------------> Item.class
>
> v v
> Container.java Item.java
>
> * Container.class depends on Container.java
> * Container.class depends on Item.class
> * Item.class depends on Item.java
> * Item.class depends on Container.class
>
> However, if you run "javac -Xprefer:source", I *think* it looks like
> this:
>
> Container.class-------+ +-----Item.class
>
> v +----|-----+ v
> Container.java <-+ +---------> Item.java
>
> I have no idea why anyone would want to compile Java this way. I only
> learned about that option earlier today, browsing the archives of the
> tup-users mailing list. (Yes, tup also has problems with Java. I
> gather from the list that other languages/compilers play similar
> tricks, e.g. Vala and Erlang.)
>
> Greg
If you run "javac -X" on the command line, you'll see (among other things)...
-Xprefer:{source,newer} Specify which file to read when both a source file
and class file are found for an implicitly compiled class
...and I assume that some version control systems may set the source to be
older than the compiled version if you updated a checkout or decided to go
back to an earlier version in the same workspace.
_______________________________________________
Scons-dev mailing list
Scons-dev@scons.org
http://two.pairlist.net/mailman/listinfo/scons-dev
