[Scons-users] Problems with the Java builder

[Russel Winder]

On Tue, 2014-01-21 at 21:29 +0100, Dirk Bächle wrote:

Dirk,

[…]

> compiling is probably not really required, but parsing enough of Java's 

> syntax to be able to extract the infos about anonymous classes and such. 

> From this, an Emitter could then mimic the naming schemes of the 

> different Java compilers and spit out the correct list of created class 

> files.


True in principle, but… do we want the hassle?

Before going forward with anything, it would be wise to check out what
Gradle has done to support incremental compilation. I would guess that
they visit the compilation output after compilation and record it.


> > Given that the number of people working with Java who are not using

> > Gradle (or Maven (or Ant)) is tiny, there isn't really that much energy

> > available to see what might be done. Given Scala has SBT, Clojure has

> > Leiningen, and Kotlin and Ceylon nigh on require an IDE, and Gradle can

> > now process C and C++, the need to make SCons JVM language offering work

> > is receding rapidly into the distance.

> >

> This sounds to me, as if you don't plan to work on Java support for 

> SCons anymore...which is totally fine. Has there been any further 

> development or discussion together with JanNijtmans, beyond what's 

> currently available at

> 

>    http://www.scons.org/wiki/JavaStrategy


Well Gant is now basically dead, as is Ant. Gradle and Maven are the
Java tools of choice. SBT has a lot of traction amongst Scala users.
Leiningen for Closure ceylon.build for Ceylon — basically each new
language thinks it has to create a new build framework or be deemed
incapable :-)

Analogously, Go, D, and Rust are creating their own build frameworks
rather than using one of SCons, Waf, CMake, Autotools. The core issues
are:

	Lack of support for an all source at once approach.
	Lack of support for packages.


> and

> 

>    http://www.scons.org/wiki/JavaSupport

> 

> ? If yes, it would be great if we could wrap things up a little, by 

> collecting and documenting the additional findings.


I am now firmly of the view that any effort to progress JVM language
support in SCons is wasted effort. So I think deleting those documents,
or at least marking them "dead", is easier than trying to bring them up
to date.

SCons is fundamentally a C compilation system. It happens to work for C
++ (at least until C++ modules hit the streets) and LaTeX (My main use
these days!). Fortran got grafted in; mostly successfully I gather, I
don't do any Fortran that uses modules. D is a bit of a handful since
for application construction you do an "all at once" build of all
sources. For D the SCons compilation model of source → object is only
really useful for library building.


> I'll continue my work on an Ant-like recursive Glob() soon, which would 

> also help for Java projects. If we then overcome the Emitter problem 

> somehow, do you think we could get back in the game? Or are the other 

> obstacles you mentioned, like support for code coverage tools, equally 

> big and hard to tackle?


I think this would a good thing whatever happens re Java support. I
often want to use this in SCons already :-)

-- 
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