[Scons-users] Problems with the Java builder

Russel Winder russel at winder.org.uk
Fri Jan 24 07:22:52 EST 2014


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



More information about the Scons-users mailing list