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
signature.asc
Description: PGP signature