SCons support for D

[Jacob Carlborg]

On 2011-12-07 10:54, Russel Winder wrote:
> On Wed, 2011-12-07 at 20:27 +1100, Andrew Gough wrote:
> [...]
>> I think the build tool question is in need of the same level of high
>> level design and support that Steve Teale is working on for
>> std.database/std.sql.
>
> I am not sure I quite get that, sorry.
>
>> It seems there is SCons support (python), CMake, Orbit (Ruby), DSSS
>> (D1 only?), xfbuild, dake, rdmd options - I've added preliminary D
>> support to premake.
>
> As far as I am aware the C, C++, Fortran communities use Make,
> Autotools, SCons, CMake or Waf.  I suspect they have never heard of
> DSSS, xfbuild, dake or rdmd ;-)
>
>> Would it be a good idea to thrash out the arguments for/against a
>> particular tool, and build/support just one?  The community doesn't
>> seem big enough to be so fragmented.  Java has Ant, Scala has sbt  -
>> surely D should have a canonical build tool?
>
> I use SCons for much of my builds of LaTeX, C, C++, Fortran, Haskell, D,
> OCaml, etc.  It works nicely for multi-target, multi-platform builds.  I
> use Waf for "ship the source, compile on installation" FOSS projects.  I
> have given up on Autotools.  CMake's language is dreadful so I only use
> that if necessary.
>
> Java has Gradle, Maven, Gant, and Ant.  Using Ant for builds is like
> using assembly language to create GUI applications -- possible but not
> recommended.
>
> Scala has sbt because the Scala community couldn't abide the
> multi-languages approach, everything has to be Scala.  Clojure has a
> similar philosophy and hence Leiningen.
>
> Sure D can use D as the build specification language and follow the
> inward looking Scala and Clojure approaches of creating a new tool for
> build.  But that is just trying to create a closed system.  Is this
> closed approach really what the D community wants to do -- is following
> the Scala and Clojure philosophy desirable?
>
> The advantage of Gradle and Maven as build tools for JVM based systems
> is that you can write multi-lingual systems and build them.  Java,
> Scala, Groovy, JRuby, Clojure -- all can be used in a single system.
> sbt has problems with this since it assumes all source is Scala (more or
> less).  The Java community is rapidly giving up its "Java is all you
> need" attitude and is looking positively at the polyglot approach.
>
> D sits in a context of C, C++, Fortran (possible others?) which means
> something like SCons, Waf and CMake which has support for all these
> already baked in seems like a "less work" way forward.
>
> So the strategy is one of:
>
> Do we work with a build framework that exists and already allows serious
> build using D; or
>
> do we start from scratch with a new build framework that no-one can use
> till something is ready?

What I see as the advantage of a new build system is that it can be 
developed specifically for D which could make the tool very easy to use. 
Example:

$ tool build main.d

That's all that should be needed to build an executable. You could have 
the same in a build script:

// buildfile
main.d

$ tool build

For a library it should be similar:

$ tool build foo

Where "foo" is a directory. I don't know if that's possible to have in a 
build tool not specifically developed for D.

-- 
/Jacob Carlborg