[Scons-users] Scala-Support

[Russel Winder]

On Mon, 2012-09-03 at 17:17 -0400, Greg Ward wrote:
[….]

> I have come to the unfortunate conclusion that SCons just can't handle

> Java in the general case, at least not without major refactoring.

> Refactoring SCons is presumably very hard because of 1) backwards

> compatibility concerns and 2) convoluted code.


I agree this is sad, but it confirms the suspicion/hypothesis I had in
my mind.


> For "Java", read "tools that produce unpredictable outputs". There's

> nothing special about javac here, it's just a very well-known,

> prominent example of a tool with unpredictable outputs.


Well only unpredictable if you don't parse the source!  I suspect SCons
is predicated on being able to deduce all intermediate file dependencies
by a quick regular expression scan of the source. This is true for C and
C++ (#include system), feasible for the D import system I think, more or
less doable for Fortran modules and simply infeasible for Java and Scala
(because of anonymous classes).


> What is really needed is the ability to construct a "rough draft" of

> the dependency graph, and then use compiler output to see what really

> happened and feed that back into the graph for the next run. I banged

> my head against doing that with SCons for a while, and eventually gave

> up. The SCons code is just too hard to follow for me. ;-(


This is (effectively) what Gradle does. Instead of the "create the
graph" / "resolve the graph" of SCons, Gradle explicitly has multiple
phases of graph building allowing various hooks into the various phases.
In particular in this context, it allows for compilation and then
amendment of the graph to allow for addition of all the extra
compilation products.


> The *other* thing that's hard about Java, which AFAIK *no one* has

> solved, is incremental compilation. You can't understand the

> dependencies between .java source files without parsing them

> completely and understanding the type system, at which point you've

> written 30% of a Java compiler. Better just to run the compiler and

> analyze the byte code... which gets us back to feeding compiler output

> back into the DAG. Really not compatible with SCons' design, as near

> as I could tell.


As noted above Gradle does this by adding the "unpredictable"
compilation products into the graph based on the predictable naming
system of the unpredictable compilation products.


> Oh yeah, the other other thing that makes Java and SCons hard to

> combine is that Java programmers think nothing of creating new source

> files. But since SCons scales badly with size of its graph (roughly,

> number of files), build performance suffers. This starts to bite once

> you get into tens of thousands of source files.


C++ folks are not averse to this either, just not on the same scale!

-- 
Russel.
=============================================================================
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder at ekiga.net
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel at winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
Url : <http://four.pairlist.net/pipermail/scons-users/attachments/20120904/b1efe4ca/attachment.pgp>