[Scons-users] Scala-Support

[Russel Winder]

On Tue, 2012-09-04 at 09:20 +1000, Peter Gummer wrote:
[…]

> I'm curious about what is the usage scenario here. I understand why C

> or C++ programmers would want incremental compilation during the

> normal working day's code-compile-test cycle (remembering back to the

> 1980s and 1990s when I used 'make' for that purpose), but why would I

> want to use SCons for incremental Java compilation? When I'm

> programming in Java, I'm working inside Eclipse, where incremental

> builds happen in the background instantly every time I save a tiny

> change. It's similar in any other language that I've used over the

> last 15 years: Delphi, C#, Visual Basic, Eiffel ... the compiler

> figures out all the dependencies for itself and usually integrates my

> latest changes within a few seconds. Introducing something like SCons

> into an already-seamless workflow just sounds pointless to me.


I guess the answer to this is embedded in the question, why did the
Gradle people decide incremental compilation was a good thing. They all
use IntelliJ IDEA (or some Eclipse) all the time, so by your argument
have no need to look for incremental compilation, and yet they did.

I think the answer is bound up in the fact that as well as the IDE
internal compilation, all the IDEA now integrate Gradle and Maven
support so as to be able to work with them as well.

Gradle goes as far as to be able to create Eclipse and IntelliJ IDEA
proejct so that there is no replication of dependency data, it is always
stored in the Gradle file.


> My interest in SCons arises for doing complete system rebuilds,

> usually on an integration server running CruiseControl or Jenkins.

> We've been using it for that purpose for our Eiffel builds for about 6

> years, and it's great, because SCons knows the dependencies between

> the source files and the final executable or DLL and doesn't waste ten

> minutes rebuilding everything if the last commit was to something

> other than a source file. We find out immediately if there has been a

> bad commit and it automates the generation of deployment packages. I'm

> currently looking at using it for Java too (though Russel's posts have

> got me leaning towards Gradle rather than SCons, because it has better

> support for Java and Jenkins).


I guess I will have to apologize for being a Gradle advocate on a SCons
mailing list, but in the end I just live with the fact that I use SCons
(and sometimes Waf) for C++, D, LaTeX, and Gradle for anything to do
with JVM-based projects. I think I have come to terms with the fact that
there is no one build framework that will ever work for all situations.


> So I'm really at a loss to understand why anyone would want SCons to

> do incremental Java compilation.


See above. :-)

I guess the issue here is what do people using SCons rather than Gradle
or Maven for Java want, what is the use case that moves them to use
SCons rather than Gradle or Maven, and let's meet that requirement in
some way.

Just to finish:  We have not discussed what is perhaps the "elephant in
the room". Almost all Java, Scala and Groovy projects have dependencies
on artefacts stored in Maven Central (or an inside the boundary wall
partial mirror for many organizations).  We haven't even addressed this
issue as it relates to SCons, whereas Maven has a partial solution and
Gradle has tackled it properly. Especially transitive dependencies –
artefacts themselves have dependencies which are specified in meta-data
associated with the dependencies.  I can't see where the resource would
come from to tackle this is SCons, I don't think Waf has addressed it,
and it is a solved problem in Gradle. For me this ends up being a QED. 

-- 
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/3743a507/attachment.pgp>