On Tue, 06 Dec 2011 18:14:25 +0000
Russel Winder <rus...@russel.org.uk> wrote:

> SCons is a Python-based build tool to replace Make and much of the
> Autotools functionality.  It has D support as part of the core.  This
> support is though in need of development.
> 
> The new Mercurial/BitBucket infrastructure for developing SCons
> (replacing the old Subversion/Tigris set up) is now in place, a new
> release 2.1.0 has been declared and everything is open for business
> leading to a 2.2.0 release.
> 
> I got my changes to support DMD 2 into this release :-)
> 
> However, support for GDC, LDC, etc. is almost certainly still sadly
> lacking, and indeed the support for DMD almost certainly needs a
> severe refactoring and most likely a rewrite.
> 
> Rather than people having to work on a clone of SCons in order to work
> on the tool, I have created a separate Mercurial repository
> (https://bitbucket.org/russel/scons_dmd_new) as a development version
> of just the tool.  When a new version of this separate tool is
> declared I create a pull request for the SCons mainline to get the
> new version in the next version of SCons.
> 
> Is anyone else other than me interested in using SCons as a build tool
> with D code?  If there is, perhaps we can collaborate in some way to
> progress SCons support for all the various realizations of D?
> 

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.

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.

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?


-- 
Andrew Gough
M: 0408 596 656
and...@goughy.org

Attachment: signature.asc
Description: PGP signature

Reply via email to